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.

[Joshua Branson]

Post by 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.

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.

Post by Fis Trivial
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.

Post by Fis Trivial
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.

[Fis Trivial]

Post by Joshua Branson

Post by 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.

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.

Post by Joshua Branson

Post by Fis Trivial
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.

Post by Fis Trivial
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.

[Joshua Branson]

Post by Fis Trivial

Post by Joshua Branson

Post by Fis Trivial
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.

[Ludovic Courtès]

Hello,

Post by Joshua Branson

Post by 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.

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’.

[Fis Trivial]

Post by Ludovic Courtès
Hello,

Post by Joshua Branson

Post by 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.

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,
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.

Post by Ludovic Courtès
Free software that you might find of interest is POCL, an OpenCL
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

[Ludovic Courtès]

Hello,
[...]

Post by Fis Trivial

Post by Ludovic Courtès
Free software that you might find of interest is POCL, an OpenCL
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.

Post by Fis Trivial
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’.

[Fis Trivial]

Post by Ludovic Courtès
Oh sorry, I had overlooked that.

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

Post by Ludovic Courtès

Post by Fis Trivial
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.

Post by Ludovic Courtès
Anyway, I would very much welcome packa

[Ludovic Courtès]

Hi,

Post by Fis Trivial

Post by Ludovic Courtès

Post by Fis Trivial
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’.

[Fis Trivial]

Post by Ludovic Courtès
Hi,

Post by Fis Trivial

Post by Ludovic Courtès

Post by Fis Trivial
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

[Fis Trivial]

Post by Fis Trivial

Post by Ludovic Courtès
Hi,

Post by Fis Trivial

Post by Ludovic Courtès

Post by Fis Trivial
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
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.
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

[Ricardo Wurmus]

Hi,

Post by Fis Trivial
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

[Tobias Platen]

Post by Ricardo Wurmus
Hi,

Post by Fis Trivial
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

Post by Ricardo Wurmus
--
Ricardo

[Joshua Branson]

Post by Ricardo Wurmus
Hi,

Post by Fis Trivial
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

Post by Ricardo Wurmus
--
Ricardo

[Pierre Neidhardt]

Post by Joshua Branson
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.

[Jonathan Brielmaier]

Post by Pierre Neidhardt

Post by Joshua Branson
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

[Pierre Neidhardt]

@Jonathan: Thanks a lot for this thorough clarification!

[Mark H Weaver]

Hi Jonathan,

Post by Jonathan Brielmaier
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)
radeonsi: for almost all cards in the last decade (mesa/src/gallium/drivers/radeonsi)
r600: for the ones before (mesa/src/gallium/drivers/r600)
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

[Jonathan Brielmaier]

Post by Mark H Weaver
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

[Chris Marusich]

Post by Jonathan Brielmaier

Post by Mark H Weaver
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.

[Thompson, David]

Post by Chris Marusich

Post by Jonathan Brielmaier

Post by Mark H Weaver
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

[Fis Trivial]

Post by Tobias Platen

Post by Ricardo Wurmus
Hi,

Post by Fis Trivial
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.

[Fis Trivial]

Post by Ricardo Wurmus
Hi,

Post by Fis Trivial
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 t