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

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 <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37831>).

add a new gallium compute only driver for nvidia hardware, named nocl (!37831) · Merge requests · Mesa / mesa · GitLab

Depends on: !37169 (only a few commits...

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

yes yes.. I know it's annoying that it takes 2 minutes with #rusticl until you can start video editing with Davinci Resolve...

but... anyway, soon you'll only have to wait 2 seconds (if your CPU is beefy enough) 🙃

hopefully that perf optimization lands with mesa 25.3

Sean has been working on something for ya (and I've been helping identifying bottlenecks and stalls to make it even better): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36740

Draft: rusticl: parallelize compilation of kernels (!36740) · Merge requests · Mesa / mesa · GitLab

What does this MR do and why? Compile each kernel in its own worker queue job to hopefully improve performance when...

GitLab

Anybody ever ran into synchronization issues with e.g. Davinci Resolve and #Rusticl ?

I fixed some issues with gl_sharing and wondering if that resolves it for everybody as well: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36249

rusticl: Fix gl_interop synchronization issues (!36249) · Merge requests · Mesa / mesa · GitLab

We only synchronized the imported GL objects on import, however we need to do so also on each clEnqueueAcquireGLObjects call to have all writes from the GL...

GitLab
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?

#rusticl implements only #OpenCL 1.1 for #AMD Southern Islands, Sea
Islands, Volcanic
Islands, Arctic
Islands/Polaris, Vega GPUs. Folding@home needs OpenCL 1.2.

And I do not believe OpenCL 1.2 will be added to rusticl for GPUs from Jun 2017 and older. 🤬

Symbol linking nightmare ...

In #fosphor I try to make use CL/GL interop.

When used inside gnuradio the whole GL thing will end up being loaded first and apparently GLX will be loaded with RTLD_LOCAL.

So when CL driver (either #rusticl or intel-compute-runtime) tries to find glXGetProcAddress using dlsym, because those are dynamically loaded after GLX and don't link to GLX themselves, they just get NULL.

My best work around so far is call dlopen("libGLX.so.0", RTLD_GLOBAL) in fosphor 😭 🤢

The #mesa 24.3 release is, as usual, pretty neat. Some random personal highlights:
1. #Rusticl for freedreno. While not enabled by default yet, this finally brings OpenCL support to QC devices. How useful that is remains to be seen, given that Vulkan also slowly evolves as compute platform - it could come in pretty handy for image related tasks, though, especially on #linuxmobile devices.

1/3

And another btw: I have Shared Virtual Memory implemented in Rusticl on top of Iris (Intel) and radeonsi (AMD) and the mechanism for that is driver independent, so...

yes, SVM in #rusticl will work across devices of different vendors once it's all finished. I still have a couple of bugs to sort out, but yeah :)