Kind of disappointing that the Guix pytorch package has no GPU support:
https://guix.gnu.org/en/packages/python-pytorch-1.12.0/
This makes me wonder if Guix is ready for the real world.
https://guix.gnu.org/en/packages/python-pytorch-1.12.0/
This makes me wonder if Guix is ready for the real world.
ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
Furthermore, you can install Nix in Guix: https://guix.gnu.org/packages/nix-2.5.1
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
ML is also increasingly relevant for OSes, think OCR and speech recognition, but also painting programs. Image classification and segmentation are used in industrial systems; lots of ML happens on servers. And this is where Linux shines, and thus support from Guix would be great. Categorically excluding this group of GPU users is a mistake.
> One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
They are. But their packaging systems are not.
That firmware could literally ship on the card totally invisibly and that would be fine for guix, but because it can be patched in the field, no.
I don't get it.
# du -bs gpu/
2053094 gpu
But there are some spectre and meltdown mitigations that comes with CPU microcode, right? It's probably not a great idea to not apply microcode updates in this case
I think Guix is more than ready for providing development environments, even for proprietary apps on open source technology stacks (but Nix will probably be easier to pitch). As an operating system much less so.
nVidia? Nix? Or Nonguix?
Don't forget about non-GNU.
If you do know the build options to make this work, Guix will gladly consider your patch.
The in-progress diff would be,
diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm
index e702e499fc..73af29487d 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -101,6 +101,7 @@ (define-module (gnu packages machine-learning)
#:use-module (gnu packages swig)
#:use-module (gnu packages tls)
#:use-module (gnu packages video)
+ #:use-module (gnu packages vulkan)
#:use-module (gnu packages web)
#:use-module (gnu packages xml)
#:use-module (gnu packages xorg)
@@ -2897,6 +2898,10 @@ (define-public python-pytorch
(build-system python-build-system)
(arguments
'(#:phases (modify-phases %standard-phases
+ (add-before 'build 'use-vulkan
+ (lambda _
+ (setenv "USE_VULKAN" "1")
+ (setenv "USE_VULKAN_SHADERC_RUNTIME" "1")))
(add-before 'build 'use-system-libraries
(lambda\* (#:key outputs #:allow-other-keys)
;; Tell 'setup.py' to let 'CMakeLists.txt' know that we
@@ -2973,7 +2978,11 @@ (define-public python-pytorch
pthreadpool
protobuf
pybind11
+ shaderc
sleef
+ glslang spirv-headers ;spirv-tools ; not sure why this is needed
+ vulkan-headers
+ vulkan-loader
xnnpack
zstd))
(propagated-inputs
FAILED: bin/scalar_test ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `glslang::TShader::setNanMinMaxClamp(bool)'
ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `spvtools::CreateCompactIdsPass()'
[...]
So that's why it's not enabled.
There's a shaderc_combined.pc in shaderc, but it doesn't lists glslang or spirv as dependencies, even though shaderc uses glslang and spirv data structures and functions. Errrrr. How's that supposed to work?