Have GPGPU support in guix?

Have GPGPU support in guix?

[Fis Trivial]

Hi Guixs, this is actually a feature wish.

I tried to use guix to manage many of my softwares on my system, but
some dependencies are missing which is blocking a full transition to
Guix based system and development environment. Most notably is GPU
computing support.

My daily routine is doing machine learning, which requires GPU for
computing nowadays. Currently I need to use CUDA from NVidia, as many of
you might know, it's not free software, not even an open source
software. However, it's the de fato toolchain in deep learning
community, so basically it's a must have dependency for most of the
related libraries if you want decent performance. Time passes and
hardwork have been done, now we have some libraries ported to OpenCL or
HIP (from AMD), it's not mature yet but I think we have a pretty good
shot at working them out in near future.

However, I wanted to manage all of these with guix so that we can have a
unified dependency tree. Currently there are a few options for OpenCL
runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
project and the implementation in mesa.

I tried to package beignet (an old OpenCL runtime from Intel) but it
wasn't successful due to failed tests (it failed from recognizing
device).
https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm

To support GPU computing, we need a full stack of softwares, from kernel
to user space libraries. When it comes to low level part I got have
litte to no knowledge, so I am hoping someone here can provide some
help/insight for having GPU computing libraries in Guix.

Thanks.

Re: Have GPGPU support in guix?

[Joshua Branson]

Fis Trivial <ybbs.daans@hotmail.com> writes:

> Hi Guixs, this is actually a feature wish.
>
> I tried to use guix to manage many of my softwares on my system, but
> some dependencies are missing which is blocking a full transition to
> Guix based system and development environment. Most notably is GPU
> computing support.
>
> My daily routine is doing machine learning, which requires GPU for
> computing nowadays. Currently I need to use CUDA from NVidia, as many of
> you might know, it's not free software, not even an open source
> software. However, it's the de fato toolchain in deep learning
> community, so basically it's a must have dependency for most of the
> related libraries if you want decent performance. Time passes and
> hardwork have been done, now we have some libraries ported to OpenCL or
> HIP (from AMD), it's not mature yet but I think we have a pretty good
> shot at working them out in near future.

Since this is a GNU endorsed distro, guixSD will never have an official
way to install or use CUDA.  There might eventually be an unofficial way
to install it someday via a guile potlock (or is it the guild command).
But I wouldn't recommend using it.  No one will seriously test it or
ensure that it works well.

>
> However, I wanted to manage all of these with guix so that we can have a
> unified dependency tree. Currently there are a few options for OpenCL
> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
> project and the implementation in mesa.

This is probably doable.

>
> I tried to package beignet (an old OpenCL runtime from Intel) but it
> wasn't successful due to failed tests (it failed from recognizing
> device).
> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>
> To support GPU computing, we need a full stack of softwares, from kernel
> to user space libraries. When it comes to low level part I got have
> litte to no knowledge, so I am hoping someone here can provide some
> help/insight for having GPU computing libraries in Guix.
>
> Thanks.

Re: Have GPGPU support in guix?

[Fis Trivial]

Joshua Branson writes:

> Fis Trivial <ybbs.daans@hotmail.com> writes:
>
>> Hi Guixs, this is actually a feature wish.
>>
>> I tried to use guix to manage many of my softwares on my system, but
>> some dependencies are missing which is blocking a full transition to
>> Guix based system and development environment. Most notably is GPU
>> computing support.
>>
>> My daily routine is doing machine learning, which requires GPU for
>> computing nowadays. Currently I need to use CUDA from NVidia, as many of
>> you might know, it's not free software, not even an open source
>> software. However, it's the de fato toolchain in deep learning
>> community, so basically it's a must have dependency for most of the
>> related libraries if you want decent performance. Time passes and
>> hardwork have been done, now we have some libraries ported to OpenCL or
>> HIP (from AMD), it's not mature yet but I think we have a pretty good
>> shot at working them out in near future.
>
> Since this is a GNU endorsed distro, guixSD will never have an official
> way to install or use CUDA.  There might eventually be an unofficial way
> to install it someday via a guile potlock (or is it the guild command).
> But I wouldn't recommend using it.  No one will seriously test it or
> ensure that it works well.
>

I want to get rid of CUDA, I am really tired of dealing with it. That's
why I'm counting on OpenCL or HIP.

>>
>> However, I wanted to manage all of these with guix so that we can have a
>> unified dependency tree. Currently there are a few options for OpenCL
>> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
>> project and the implementation in mesa.
>
> This is probably doable.
>
>>
>> I tried to package beignet (an old OpenCL runtime from Intel) but it
>> wasn't successful due to failed tests (it failed from recognizing
>> device).
>> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>>
>> To support GPU computing, we need a full stack of softwares, from kernel
>> to user space libraries. When it comes to low level part I got have
>> litte to no knowledge, so I am hoping someone here can provide some
>> help/insight for having GPU computing libraries in Guix.
>>
>> Thanks.

Thanks.

Re: Have GPGPU support in guix?

[Joshua Branson]

Fis Trivial <ybbs.daans@hotmail.com> writes:

> Joshua Branson writes:
>
>> Fis Trivial <ybbs.daans@hotmail.com> writes:
>>
>>> Hi Guixs, this is actually a feature wish.
>>>
>>> My daily routine is doing machine learning, which requires GPU for
>>> computing nowadays. Currently I need to use CUDA from NVidia, as many of
>>> you might know, it's not free software, not even an open source
>>> software. However, it's the de fato toolchain in deep learning
>>> community, so basically it's a must have dependency for most of the
>>> related libraries if you want decent performance. Time passes and
>>> hardwork have been done, now we have some libraries ported to OpenCL or
>>> HIP (from AMD), it's not mature yet but I think we have a pretty good
>>> shot at working them out in near future.
>>
>> Since this is a GNU endorsed distro, guixSD will never have an official
>> way to install or use CUDA.  There might eventually be an unofficial way
>> to install it someday via a guile potlock (or is it the guild command).
>> But I wouldn't recommend using it.  No one will seriously test it or
>> ensure that it works well.
>>
>
> I want to get rid of CUDA, I am really tired of dealing with it. That's
> why I'm counting on OpenCL or HIP.

Ok. cool!  I'm not sure that Nvidia is currently supporting the later
versions of openCL. Kind of sad really.

Re: Have GPGPU support in guix?

[Ludovic Courtès]

Hello,

Joshua Branson <jbranso@fastmail.com> skribis:

> Fis Trivial <ybbs.daans@hotmail.com> writes:
>
>> Hi Guixs, this is actually a feature wish.
>>
>> I tried to use guix to manage many of my softwares on my system, but
>> some dependencies are missing which is blocking a full transition to
>> Guix based system and development environment. Most notably is GPU
>> computing support.
>>
>> My daily routine is doing machine learning, which requires GPU for
>> computing nowadays. Currently I need to use CUDA from NVidia, as many of
>> you might know, it's not free software, not even an open source
>> software. However, it's the de fato toolchain in deep learning
>> community, so basically it's a must have dependency for most of the
>> related libraries if you want decent performance. Time passes and
>> hardwork have been done, now we have some libraries ported to OpenCL or
>> HIP (from AMD), it's not mature yet but I think we have a pretty good
>> shot at working them out in near future.
>
> Since this is a GNU endorsed distro, guixSD will never have an official
> way to install or use CUDA.

Indeed.  Specifically, the project is committed to following the FSDG,
so CUDA doesn’t belong in Guix:

  https://gnu.org/distros/free-system-distribution-guidelines.html

Free software that you might find of interest is POCL, an OpenCL
implementation (not yet packaged in Guix):

  https://github.com/pocl/pocl

Ludo’.

Re: Have GPGPU support in guix?

[Ricardo Wurmus]

Hi,

> I tried to use guix to manage many of my softwares on my system, but
> some dependencies are missing which is blocking a full transition to
> Guix based system and development environment. Most notably is GPU
> computing support.
>
> My daily routine is doing machine learning, which requires GPU for
> computing nowadays.

I’m currently working on packaging Tensorflow (without GPU support).  I
don’t know if Tensorflow with GPU support will work with OpenCL.

--
Ricardo

Re: Have GPGPU support in guix?

[Tobias Platen]

On 25.04.2018 19:17, Ricardo Wurmus wrote:
>
> Hi,
>
>> I tried to use guix to manage many of my softwares on my system, but
>> some dependencies are missing which is blocking a full transition to
>> Guix based system and development environment. Most notably is GPU
>> computing support.
>>
>> My daily routine is doing machine learning, which requires GPU for
>> computing nowadays.
>
> I’m currently working on packaging Tensorflow (without GPU support).  I
> don’t know if Tensorflow with GPU support will work with OpenCL.
I don't think that any modern GPU will be supported without non-free 
software. Many of them require blobs for power management and 
instruction scheduling.

Tobias Platen
>
> --
> Ricardo
>
>
>

Re: Have GPGPU support in guix?

[Joshua Branson]

Tobias Platen <trisquel@platen-software.de> writes:

> On 25.04.2018 19:17, Ricardo Wurmus wrote:
>>
>> Hi,
>>
>>> I tried to use guix to manage many of my softwares on my system, but
>>> some dependencies are missing which is blocking a full transition to
>>> Guix based system and development environment. Most notably is GPU
>>> computing support.
>>>
>>> My daily routine is doing machine learning, which requires GPU for
>>> computing nowadays.
>>
>> I’m currently working on packaging Tensorflow (without GPU support).  I
>> don’t know if Tensorflow with GPU support will work with OpenCL.
> I don't think that any modern GPU will be supported without non-free software. Many of them require blobs for power management and
> instruction scheduling.

That's actually a really good point.  I forgot about that.  Isn't radeon
close to having free drivers?

>
> Tobias Platen
>>
>> --
>> Ricardo
>>
>>
>>

Re: Have GPGPU support in guix?

[Fis Trivial]

Ludovic Courtès writes:

> Hello,
>
> Joshua Branson <jbranso@fastmail.com> skribis:
>
>> Fis Trivial <ybbs.daans@hotmail.com> writes:
>>
>>> Hi Guixs, this is actually a feature wish.
>>>
>>> I tried to use guix to manage many of my softwares on my system, but
>>> some dependencies are missing which is blocking a full transition to
>>> Guix based system and development environment. Most notably is GPU
>>> computing support.
>>>
>>> My daily routine is doing machine learning, which requires GPU for
>>> computing nowadays. Currently I need to use CUDA from NVidia, as many of
>>> you might know, it's not free software, not even an open source
>>> software. However, it's the de fato toolchain in deep learning
>>> community, so basically it's a must have dependency for most of the
>>> related libraries if you want decent performance. Time passes and
>>> hardwork have been done, now we have some libraries ported to OpenCL or
>>> HIP (from AMD), it's not mature yet but I think we have a pretty good
>>> shot at working them out in near future.
>>
>> Since this is a GNU endorsed distro, guixSD will never have an official
>> way to install or use CUDA.
>
> Indeed.  Specifically, the project is committed to following the FSDG,
> so CUDA doesn’t belong in Guix:
>
>   https://gnu.org/distros/free-system-distribution-guidelines.html
>

Sorry that I didn't make it clear in the original mail. The reason I
talked about CUDA, is to express, that's the one thing I want to get rid
of and replace it with Other free alternatives listed in original mail.
But I need help packaging those free alternatives.

> Free software that you might find of interest is POCL, an OpenCL
> implementation (not yet packaged in Guix):
>
>   https://github.com/pocl/pocl
>

I mentioned it in the original mail. But packaging these thing requires
knowledge for kernel space stuffs, like kernel module for GPU, which I
don't have. So, any help is appreciated.

> Ludo’.

Thanks.

Re: Have GPGPU support in guix?

[Fis Trivial]

Ricardo Wurmus writes:

> Hi,
>
>> I tried to use guix to manage many of my softwares on my system, but
>> some dependencies are missing which is blocking a full transition to
>> Guix based system and development environment. Most notably is GPU
>> computing support.
>>
>> My daily routine is doing machine learning, which requires GPU for
>> computing nowadays.
>
> I’m currently working on packaging Tensorflow (without GPU support).  I
> don’t know if Tensorflow with GPU support will work with OpenCL.

No, it doesn't. It do support sycl[1]. But again, there's no usable free
implementation of sycl that supports GPU.

[1]: https://www.khronos.org/sycl

Re: Have GPGPU support in guix?

[Fis Trivial]

Tobias Platen writes:

> On 25.04.2018 19:17, Ricardo Wurmus wrote:
>>
>> Hi,
>>
>>> I tried to use guix to manage many of my softwares on my system, but
>>> some dependencies are missing which is blocking a full transition to
>>> Guix based system and development environment. Most notably is GPU
>>> computing support.
>>>
>>> My daily routine is doing machine learning, which requires GPU for
>>> computing nowadays.
>>
>> I’m currently working on packaging Tensorflow (without GPU support).  I
>> don’t know if Tensorflow with GPU support will work with OpenCL.
> I don't think that any modern GPU will be supported without non-free
> software. Many of them require blobs for power management and
> instruction scheduling.
>

That would be a really, really bad news.

> Tobias Platen
>>
>> --
>> Ricardo
>>
>>
>>

Re: Have GPGPU support in guix?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]


Joshua Branson <jbranso@fastmail.com> writes:

> That's actually a really good point.  I forgot about that.  Isn't radeon
> close to having free drivers?

I thought it was entirely free already, isn't it?
To my understanding, it's AMDGPU that is partly proprietary.
According to the latest Phoronix benchmarks, the free Radeon performs
really well.

I don't know about OpenCL though.

-- 
Pierre Neidhardt

Once, I read that a man be never stronger than when he truly realizes how
weak he is.
		-- Jim Starlin, "Captain Marvel #31"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Have GPGPU support in guix?

[Jonathan Brielmaier]

On 04/26/2018 05:18 AM, Pierre Neidhardt wrote:
> 
> Joshua Branson <jbranso@fastmail.com> writes:
> 
>> That's actually a really good point.  I forgot about that.  Isn't radeon
>> close to having free drivers?
> 
> I thought it was entirely free already, isn't it?
> To my understanding, it's AMDGPU that is partly proprietary.
> According to the latest Phoronix benchmarks, the free Radeon performs
> really well.

There is a bunch of entirely FOSS drivers for AMD Radeon cards:

Kernel drivers:
radeon: for older cards before GCN1.2 (kernel/drivers/gpu/drm/radeon)
amdgpu: for the new cards since GCN1.2 (kernel/drivers/gpu/drm/amd/amdgpu)

Userspace drivers:
radeonsi: for almost all cards in the last decade (mesa/src/gallium/drivers/radeonsi)
r600: for the ones before (mesa/src/gallium/drivers/r600)

Vulkan drivers:
RADV: written by the community (RedHat etc.), because AMD initially didn't make their Vulkan
userspace FOSS (mesa/src/amd/vulkan)
AMDVLK: AMDs Vulkan driver released as FOSS (https://github.com/GPUOpen-Drivers/AMDVLK)

So your FOSS driver would consist of amdgpu + radeonsi + radv and is in almost all cases the
best choice (performance, stability etc).

Then there was always a propriatary driver by AMD nowadays it's called "Radeon Software for Linux",
which bundles also free software like AMDVLK and ROCm. Other names before were "AMDGPU-PRO", 
"AMD Catalyst" and "fglrx"...

I hope it's now less confusing then before :P
Jonathan

Re: Have GPGPU support in guix?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 86 bytes --]


@Jonathan:  Thanks a lot for this thorough clarification!

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Have GPGPU support in guix?

[Mark H Weaver]

Hi Jonathan,

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> There is a bunch of entirely FOSS drivers for AMD Radeon cards:
>
> Kernel drivers:
> radeon: for older cards before GCN1.2 (kernel/drivers/gpu/drm/radeon)
> amdgpu: for the new cards since GCN1.2 (kernel/drivers/gpu/drm/amd/amdgpu)
>
> Userspace drivers:
> radeonsi: for almost all cards in the last decade (mesa/src/gallium/drivers/radeonsi)
> r600: for the ones before (mesa/src/gallium/drivers/r600)
>
> Vulkan drivers:
> RADV: written by the community (RedHat etc.), because AMD initially didn't make their Vulkan
> userspace FOSS (mesa/src/amd/vulkan)
> AMDVLK: AMDs Vulkan driver released as FOSS (https://github.com/GPUOpen-Drivers/AMDVLK)
>
> So your FOSS driver would consist of amdgpu + radeonsi + radv and is in almost all cases the
> best choice (performance, stability etc).

What about firmware?  Do we know which AMD Radeon cards, if any, can be
used without including nonfree software in the OS?

A quick web search would seem to suggest that on Debian, it is very
commonly required to install the 'firmware-linux-nonfree' and/or
'firmware-amd-graphics' packages from non-free.

     Thanks,
       Mark

Re: Have GPGPU support in guix?

[Jonathan Brielmaier]

On 26/04/2018 10:04, Mark H Weaver wrote:
> What about firmware?  Do we know which AMD Radeon cards, if any, can be
> used without including nonfree software in the OS?

I'm not aware of an AMD/ATI Radeon card which doesn't need nonfree
firmware. The in-tree firmware in kernel goes back until ATI Radeon
R100[0], out-tree (linux-firmware.git) are all cards who run the amdgpu,
radeon or r600 kernel driver. So no card without nonfree firmware in the
last ~20 years...

There could be some Nvidia cards who doesn't need nonfree firmware
according to [1]. It have to be before Geforce 8000[2].

AFAIK Intel integrated GPUs didn't need nonfree firmware.

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/firmware/radeon?h=v4.4.129
[1]
https://unix.stackexchange.com/questions/393504/which-amd-ati-cards-dont-require-non-free-firmware-when-using-radeon
[2] https://en.wikipedia.org/wiki/GeForce_8_series

Re: Have GPGPU support in guix?

[Ludovic Courtès]

Hello,

Fis Trivial <ybbs.daans@hotmail.com> skribis:

> Ludovic Courtès writes:

[...]

>> Free software that you might find of interest is POCL, an OpenCL
>> implementation (not yet packaged in Guix):
>>
>>   https://github.com/pocl/pocl
>>
>
> I mentioned it in the original mail. But packaging these thing requires
> knowledge for kernel space stuffs, like kernel module for GPU, which I
> don't have. So, any help is appreciated.

Oh sorry, I had overlooked that.

You wrote:

> However, I wanted to manage all of these with guix so that we can have a
> unified dependency tree. Currently there are a few options for OpenCL
> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
> project and the implementation in mesa.
> 
> I tried to package beignet (an old OpenCL runtime from Intel) but it
> wasn't successful due to failed tests (it failed from recognizing
> device).
> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm

Regarding failed tests, I think that tests that expect GPU devices to be
able are likely to fail: it could be that the relevant /dev nodes are
inaccessible to the build users, or, more importantly, it could be that
we’re building on a GPU-less machine such as our build farm.  So these
tests would have to be skipped.

Anyway, I would very much welcome packages in this area!

Ludo’.

Re: Have GPGPU support in guix?

[Fis Trivial]

>
> Oh sorry, I had overlooked that.
>

No problem, I really appreciate all the hardwork you have done, thanks. :)

> You wrote:
>
>> However, I wanted to manage all of these with guix so that we can have a
>> unified dependency tree. Currently there are a few options for OpenCL
>> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
>> project and the implementation in mesa.
>> 
>> I tried to package beignet (an old OpenCL runtime from Intel) but it
>> wasn't successful due to failed tests (it failed from recognizing
>> device).
>> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>
> Regarding failed tests, I think that tests that expect GPU devices to be
> able are likely to fail: it could be that the relevant /dev nodes are
> inaccessible to the build users, or, more importantly, it could be that
> we’re building on a GPU-less machine such as our build farm.  So these
> tests would have to be skipped.

I think we might need a better scheme other than skipping tests to
verify the usability of these packages. If we skip tests for OpenCL
runtime, then all the other packages (I promise it will be A LOT) that
depend on it will need to skip their tests, since they won't run without
a proper runtime, resulting in a whole tree of untested packages. And
these thing break easily, due to the fact that they usually rely on
specific version of Clang and LLVM, and many of them still in heavy
development stage.

>
> Anyway, I would very much welcome packages in this area!
>
> Ludo’.

Re: Have GPGPU support in guix?

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> On 26/04/2018 10:04, Mark H Weaver wrote:
>> What about firmware?  Do we know which AMD Radeon cards, if any, can be
>> used without including nonfree software in the OS?
>
> I'm not aware of an AMD/ATI Radeon card which doesn't need nonfree
> firmware. The in-tree firmware in kernel goes back until ATI Radeon
> R100[0], out-tree (linux-firmware.git) are all cards who run the amdgpu,
> radeon or r600 kernel driver. So no card without nonfree firmware in the
> last ~20 years...
>
> There could be some Nvidia cards who doesn't need nonfree firmware
> according to [1]. It have to be before Geforce 8000[2].
>
> AFAIK Intel integrated GPUs didn't need nonfree firmware.
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/firmware/radeon?h=v4.4.129
> [1]
> https://unix.stackexchange.com/questions/393504/which-amd-ati-cards-dont-require-non-free-firmware-when-using-radeon
> [2] https://en.wikipedia.org/wiki/GeForce_8_series

Are there any new graphics cards being made today by anybody, which do
not require non-free firmware?  I don't know much about the state of
graphics cards in the GNU/Linux world, but I'm very curious about it.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Have GPGPU support in guix?

[Ludovic Courtès]

Hi,

Fis Trivial <ybbs.daans@hotmail.com> skribis:

>>> However, I wanted to manage all of these with guix so that we can have a
>>> unified dependency tree. Currently there are a few options for OpenCL
>>> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
>>> project and the implementation in mesa.
>>> 
>>> I tried to package beignet (an old OpenCL runtime from Intel) but it
>>> wasn't successful due to failed tests (it failed from recognizing
>>> device).
>>> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>>
>> Regarding failed tests, I think that tests that expect GPU devices to be
>> able are likely to fail: it could be that the relevant /dev nodes are
>> inaccessible to the build users, or, more importantly, it could be that
>> we’re building on a GPU-less machine such as our build farm.  So these
>> tests would have to be skipped.
>
> I think we might need a better scheme other than skipping tests to
> verify the usability of these packages. If we skip tests for OpenCL
> runtime, then all the other packages (I promise it will be A LOT) that
> depend on it will need to skip their tests, since they won't run without
> a proper runtime, resulting in a whole tree of untested packages. And
> these thing break easily, due to the fact that they usually rely on
> specific version of Clang and LLVM, and many of them still in heavy
> development stage.

Are you sure?  What I would expect is that packages would be able to use
the OpenCL run-time, they’d even be able to run OpenCL code as part of
their tests, only it would run on the main CPU instead of on GPUs, as if
the machine had no usable GPUs.

Does that make sense?

Thanks,
Ludo’.

Re: Have GPGPU support in guix?

[Fis Trivial]

Ludovic Courtès writes:

> Hi,
>
> Fis Trivial <ybbs.daans@hotmail.com> skribis:
>
>>>> However, I wanted to manage all of these with guix so that we can have a
>>>> unified dependency tree. Currently there are a few options for OpenCL
>>>> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
>>>> project and the implementation in mesa.
>>>>
>>>> I tried to package beignet (an old OpenCL runtime from Intel) but it
>>>> wasn't successful due to failed tests (it failed from recognizing
>>>> device).
>>>> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>>>
>>> Regarding failed tests, I think that tests that expect GPU devices to be
>>> able are likely to fail: it could be that the relevant /dev nodes are
>>> inaccessible to the build users, or, more importantly, it could be that
>>> we’re building on a GPU-less machine such as our build farm.  So these
>>> tests would have to be skipped.
>>
>> I think we might need a better scheme other than skipping tests to
>> verify the usability of these packages. If we skip tests for OpenCL
>> runtime, then all the other packages (I promise it will be A LOT) that
>> depend on it will need to skip their tests, since they won't run without
>> a proper runtime, resulting in a whole tree of untested packages. And
>> these thing break easily, due to the fact that they usually rely on
>> specific version of Clang and LLVM, and many of them still in heavy
>> development stage.
>
> Are you sure?  What I would expect is that packages would be able to use
> the OpenCL run-time, they’d even be able to run OpenCL code as part of
> their tests, only it would run on the main CPU instead of on GPUs, as if
> the machine had no usable GPUs.
>
> Does that make sense?
>
> Thanks,
> Ludo’.

In most of the time, we have two way to run these packages on CPU, For
the first one:

Most of the packages have a CPU backend and an OpenCL backend,
implementing same algorithms twice, so when OpenCL device is not
available, they will run on their CPU backend. And the normal testing
scheme for these packages is doing the same tests for each backend, but
do them independently. So, if we were to put these packages in Guix, we
could run the tests for CPU backend.

For the second one:

OpenCL implementations (the compiler) have a fall back mode, which means
they can treat CPU as the device and compile OpenCL code to run it on
CPU. I think this is what you meant by the line "run OpenCL code as part
of their tests". This feature is provided by the OpenCL compiler, which
we currently can't test.

I'm still trying to package a basic OpenCL stack. And I did success in
run some very primitive tests from myself outside of the store. But
still, there are a lots of stuffs I need to learn.

Re: Have GPGPU support in guix?

[Fis Trivial]

Fis Trivial writes:

> Ludovic Courtès writes:
>
>> Hi,
>>
>> Fis Trivial <ybbs.daans@hotmail.com> skribis:
>>
>>>>> However, I wanted to manage all of these with guix so that we can have a
>>>>> unified dependency tree. Currently there are a few options for OpenCL
>>>>> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
>>>>> project and the implementation in mesa.
>>>>>
>>>>> I tried to package beignet (an old OpenCL runtime from Intel) but it
>>>>> wasn't successful due to failed tests (it failed from recognizing
>>>>> device).
>>>>> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>>>>
>>>> Regarding failed tests, I think that tests that expect GPU devices to be
>>>> able are likely to fail: it could be that the relevant /dev nodes are
>>>> inaccessible to the build users, or, more importantly, it could be that
>>>> we’re building on a GPU-less machine such as our build farm.  So these
>>>> tests would have to be skipped.
>>>
>>> I think we might need a better scheme other than skipping tests to
>>> verify the usability of these packages. If we skip tests for OpenCL
>>> runtime, then all the other packages (I promise it will be A LOT) that
>>> depend on it will need to skip their tests, since they won't run without
>>> a proper runtime, resulting in a whole tree of untested packages. And
>>> these thing break easily, due to the fact that they usually rely on
>>> specific version of Clang and LLVM, and many of them still in heavy
>>> development stage.
>>
>> Are you sure?  What I would expect is that packages would be able to use
>> the OpenCL run-time, they’d even be able to run OpenCL code as part of
>> their tests, only it would run on the main CPU instead of on GPUs, as if
>> the machine had no usable GPUs.
>>
>> Does that make sense?
>>
>> Thanks,
>> Ludo’.
>
> In most of the time, we have two way to run these packages on CPU, For
> the first one:
>
> Most of the packages have a CPU backend and an OpenCL backend,
> implementing same algorithms twice, so when OpenCL device is not
> available, they will run on their CPU backend. And the normal testing
> scheme for these packages is doing the same tests for each backend, but
> do them independently. So, if we were to put these packages in Guix, we
> could run the tests for CPU backend.
>
> For the second one:
>
> OpenCL implementations (the compiler) have a fall back mode, which means
> they can treat CPU as the device and compile OpenCL code to run it on
> CPU. I think this is what you meant by the line "run OpenCL code as part
> of their tests". This feature is provided by the OpenCL compiler, which
> we currently can't test.
>
> I'm still trying to package a basic OpenCL stack. And I did success in
> run some very primitive tests from myself outside of the store. But
> still, there are a lots of stuffs I need to learn.

And to make things more complicated, developers can choose platforms(the
implementations), device at runtime, if the package developers choose to
run the code with GPU, then falling back to CPU won't happen. I'm
thinking putting tests executable as a separated output for those who
want to run tests. But simply copying executable files will result in
wrong rpath, which is another thing I don't know how to deal with.

Currently, using clinfo (A little utility used to display information
about existing OpenCL vendor information) to display information about
*beignet* and *pocl* is working, which means calling basic functions
with packages in the store is working. You can check the code
in (or would it be more convenient if I open a bug report and drop the
code there?):

https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm

I also put a readme file in that repository.

Re: Have GPGPU support in guix?

[Thompson, David]

On Thu, Apr 26, 2018 at 11:31 PM, Chris Marusich <cmmarusich@gmail.com> wrote:
> Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:
>
>> On 26/04/2018 10:04, Mark H Weaver wrote:
>>> What about firmware?  Do we know which AMD Radeon cards, if any, can be
>>> used without including nonfree software in the OS?
>>
>> I'm not aware of an AMD/ATI Radeon card which doesn't need nonfree
>> firmware. The in-tree firmware in kernel goes back until ATI Radeon
>> R100[0], out-tree (linux-firmware.git) are all cards who run the amdgpu,
>> radeon or r600 kernel driver. So no card without nonfree firmware in the
>> last ~20 years...
>>
>> There could be some Nvidia cards who doesn't need nonfree firmware
>> according to [1]. It have to be before Geforce 8000[2].
>>
>> AFAIK Intel integrated GPUs didn't need nonfree firmware.
>>
>> [0]
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/firmware/radeon?h=v4.4.129
>> [1]
>> https://unix.stackexchange.com/questions/393504/which-amd-ati-cards-dont-require-non-free-firmware-when-using-radeon
>> [2] https://en.wikipedia.org/wiki/GeForce_8_series
>
> Are there any new graphics cards being made today by anybody, which do
> not require non-free firmware?  I don't know much about the state of
> graphics cards in the GNU/Linux world, but I'm very curious about it.

I'm not aware of a single new GPU that fits the bill. Last year I
bought the most recent NVIDIA GPU I could find that works blob-free
with nouveau drivers, the GTX 770. That will last me awhile but I
don't know what I will do when it becomes too weak to handle modern
software. Furthermore, I don't know what to do when my Thinkpad X220
and it's aging Intel GPU are no longer good enough, since all new
Intel GPUs also require firmware blobs. The future looks bleak.

- Dave