sci-ml/ollama: fix broken CUDA support via dynamic GPU detection#409
sci-ml/ollama: fix broken CUDA support via dynamic GPU detection#409nabbi wants to merge 1 commit intogentoo:masterfrom
Conversation
62fdee3 to
ac741e2
Compare
|
@negril FYA |
|
We still need to address the concern of "backends end up in /usr/bin otherwise" |
|
Building without This is an issue upstream needs to fix ( and is most likely caused by the incomplete import and abuse of ggml by ollama ). You can try and see if setting
Passing The cuda changes are an amalgamation of my cuda stuff in various ebuilds. I'll see how much it differs from the wip eclass and if it makes sense to add that to ::guru for the time being. |
|
Okay. I'll tweak again with your feedback and test again, yeah I think that'll resolve the duplication. |
Fix an issue where USE=cuda builds failed to provide GPU acceleration. Previous "native" build attempts were non-functional due to sandbox restrictions and incorrect architecture targeting. - Implement smart CUDAARCHS detection using __nvcc_device_query. - Add sandbox-aware hardware check to prevent 0x64 (No Device) errors. - Disable GGML_NATIVE to ensure specific GPU kernels are generated. - Default to 'all' (fat binary) if hardware is inaccessible. - Add pkg_pretend guidance for binary package (binpkg) portability. - Fix duplicate library install. Signed-off-by: Nic Boet <nic@boet.cc>
|
Update. lmk if I missed the mark. Yes. I found various approaches of handing CMAKE_CUDA_ARCHITECTURES in the tree. Would be awesome to have some standardization in the cuda.eclass for this and documentation of a global CUDAARCHS :) |
|
|
But does it work? I'll look at the cuda stuff tomorrow. |
Yes! It's a little quirky as it's attempting to reinstall on top of libggml-cpu-x64.so and libggml-cuda.so |
Fix an issue where USE=cuda builds failed to provide GPU acceleration. Previous "native" build attempts were non-functional due to sandbox restrictions and incorrect architecture targeting.
Thanks :)