home.social

#rusticl — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #rusticl, aggregated by home.social.

  1. Interestingly, when building Pocl with the option to statically link against LLVM 18, the crash can be reproduced by simply running `clinfo -l` (which is the least-intrusive OpenCL-using command you can run, basiclaly) and the error is caused by the good old

    : CommandLine Error: Option 'internalize-public-api-file' registered more than once!
    LLVM ERROR: inconsistency in registered CommandLine options

    during the Pocl ICD device numeration.

    *sigh*

    #llvm #clang #pocl #rusticl #mesa

  2. And I'll enable the #rusticl #zink backend for funsies too, even if the performance is not the best (one of the purposes of having all these platforms supporting the same devices is to show how performance is not JUST a matter of hardware choice). Pity cluda isn't upstreamed yet.

    (For the curious: cluda is a rusticl backend for the NVIDIA binary driver, developed by
    @karolherbst —you can track its upstreaming process here <gitlab.freedesktop.org/mesa/me>).

  3. I'm double-checking I have everything ready for my #GPGPU lessons (course starts in March) and of course a recent upgrade seems to have busted #rusticl on my machine, with a #segfault somewhere in kernel compilation stage. Not happy about it, but I guess it's par of the course when running somewhat bleeding edge OSes (Debian unstable + some weird stuff). Let's see if this issue is fixed wth the version of Mesa in experimental, or if I can report the bug.

  4. I want to get #davinci_resolve working on #Fedora 42 with my now very old AMD rx480 8GB but it uses #OpenCL. The obvious choice would be #rocm but that dropped support for my GPU years ago and from what I found also causes issues with Davinci resolve for even more years. The other obvious choice would be mesas implementation but while #Rusticl improved things it's still not a feature complete implementation and rather slow. Is it smart to use the amdgpu-pro ICD with mesa drivers for this?

  5. btw, #rusticl is also conformant on #zink as of 2 or 3 weeks ago? Anyway, that's done

  6. So, I'll be having my talk about Rusticl, Compute in the linux desktop and other related topics at IWOCL next week.

    Any specifics topics you want me to cover?

    #iwocl #opencl #rusticl #linux

  7. So I actually tried to give the #HSA #PoCL driver a go, and while I didn't actually get support for my #AMD integrated #GPU (but it should be doable) I actually discovered something interesting, which I hadn't noticed since I didn't compare the `clinfo` output for my iGP between #Rusticl and the proprietary driver.

    So here's the weird thing: they report a different number of compute units!

  8. I'm still moderately annoyed by the fact that there's no single #OpenCL platform to drive all computer devices on this machine. #PoCL comes close because it supports both the CPU and the #NVIDIA dGPU through #CUDA, but the not the #AMD iGPU (there's an #HSA device, but). #Rusticl supports the iGP (radeonsi) and the CPU (llvmpipe), but not the dGPU (partly because I'm running that on proprietary drivers for CUDA). Everything else has at best one supported device out of three available.