On Fri, 23 Oct 2026 14:54:40 -0600 Cordell Bloor wrote: [...] > On 2026-10-23 10:09, Francesco Poli wrote: > > Does this also mean that I cannot (currently) use this integrated > > GPU for GPGPU computations? I haven't yet tried... > > You can use your integrated GPU for GPGPU computations, though it may > be more difficult. You have to build the code yourself rather than > relying on Debian's prebuilt packages. That means no use of the > rocblas, rocsparse, rocsolver, or rocrand packages.
Not even with the workaround you suggested for ggml HIP backend? ``` $ export HSA_OVERRIDE_GFX_VERSION=9.0.0 ``` [...] > When libraries are built for the HIP language, the GPU code generated > by the compiler is /native machine code/. This is unlike other GPU > computational frameworks like Vulkan, OpenGL, or OpenCL, where > application binaries generally either depend on run-time compilation > (RTC) of shader sources, or ship an intermediate representation of > the shaders (such as SPIR-V) and then JIT to native GPU code on the > user's machine. Is this more similar to what happens for the CUDA toolkit in NVIDIA GPUs? When you compile for NVIDIA GPUs, you target a so-called Compute Capability (CC) and the code only runs on the GPUs that correspond to that CC. There is a [table of NVIDIA CCs] which lists the compute capabilities and the corresponding GPUs. [table of NVIDIA CCs]: <https://developer.nvidia.com/cuda/gpus> By the way, I tried to search for a table which lists the architectures and the corresponding AMD GPUs. Is there such a table, as far as you know? Is it [this], maybe?!? I cannot find my APU there, though... Is there any better table? Perhaps, an [official] one? [this]: <https://llvm.org/docs/AMDGPUUsage.html> [official]: <https://rocm.docs.amd.com/en/latest/compatibility/compatibility-matrix.html> It could help me to see whether there is a dedicated graphics card (dGPU) which is well supported by ROCm and math libraries, without costing an arm and a leg... Something suitable to do some GPGPU programming: I mean, suitable for testing the correct execution of a GPGPU program, not necessarily to seriously assess its performance in HPC context... > > The HIP toolchain and runtime in Debian Testing and Unstable can > build and run GPGPU programs and libraries for gfx90c. However, the > prebuilt library and program packages included in Debian are not > built for gfx90c. If the prebuilt libggml0-backend-hip and > librocblas4 packages contained gfx90c machine code, then they would > run on your system. > > In any case, there are two main reasons why we don't build the Debian > packages for gfx90c: [...] This is very clear and illuminating, thank you so much for your kind explanations! > > > Your guess seems to be confirmed by the actual numbers. It seems > > that the Vulkan backend performs better. > > Thank you for sharing. It's always nice to see actual benchmarks to > confirm my suspicions. :-) > > > Also, if you have anything to comment about my comparison of Vulkan > > and CPU backends (why is `pp512` performance almost double, while > > `tg128` is only very slightly better), I would be very interested > > in hearing your take on that... > > I'm afraid that I don't know enough to do anything but speculate. My > suspicion would be that token generation gets little benefit from the > APU hardware because it is memory-bound and it cannot be > significantly optimized for that reason. This looks consistent with what I was reading [elsewhere]. So token generation would benefit from more memory / larger memory bandwith... [elsewhere]: <https://llmrequirements.com/cuda-vs-vulkan-llama-cpp> > Prompt processing, on the other hand, is compute-bound and there's > more room for the Vulkan implementation to distinguish itself by > making more efficient use of the APU hardware. However, this is > nothing more than a guess. Thanks anyway for sharing your insight, all this conversation is being very helpful! Your time and dedication is really appreciated. -- https://www.free-vortex.org/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpAd8oXbE2m2.pgp
Description: OpenPGP digital signature
