#rusticl — Public Fediverse posts

Guess #rusticl on #panfrost is also #OpenCL 3.0 conformant as of yesterday: https://www.khronos.org/conformance/adopters/conformant-products/opencl#submission_474

OpenCL 3.1 is in the works

To all #linux distributions out there: patch your libclc (especially the SPIR-V version) with this patch: github.com/llvm/llvm-project/pull/207264

Otherwise #rusticl is pretty broken (some applications e.g. #darktable won't work with it anymore without that patch, https://github.com/darktable-org/darktable/issues/21662)

So apparently libclc from llvm--22 has a little bug, so for #rusticl to work properly on it distribution probably want to backport this PR or wait for a new llvm 22.x release

https://github.com/llvm/llvm-project/pull/207264

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

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

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

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?

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 😭 🤢

Thank god #Rusticl exists, it has made setting up #opencl on #Linux so easy, you just install #mesa and you are done, everything "just works"

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 :)

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

Though of the day: I should make more of use lifetimes in Rust to express dependencies between API objects in #Rusticl

So far I haven't as using Arc is a good enough solution here. But I'm getting to the point where it's getting in the way.

The main reason I haven't is, that API objects are managed by the application and given #OpenCL being a C API there isn't much I can do really if the application destroys objects in a weird order.

So that's kinda annoying.

@matt yeah.. this is the main reason why with #rusticl my policy basically is "I use at most whatever FireFox ESR needs", because FireFox ESR is something every distro has to build and package unless they want to risk an insecure web browser.

Maybe at some point I should talk about some of the push back I've gotten when I proposed #rusticl to be merged into mesa.

But all in all I think we can safely say that introducing Rust to Mesa as a success.

I don't know how much that impacted @gfxstrand writing NAK in rust, but at least I've dealt with some of the meson and rust integration problems early on, so at least I enabled that to be a bit simpler than if I hadn't done that 🙃

I wished we'd had a way in #rust to say "usize is at least u32 big", because that would allow me to get rid of a loooooooot of "as" statements in #rusticl

I'm gonna fix the most annoying and most weird bug I have atm inside #rusticl : "volatile private" variables getting optimized to registers.

And you might think "why does this even remotely matter?" Turns out the #OpenCL CTS checks with a simple kernel having two constants in volatile private memory how rounding actually works on hardware.

However, we constant fold it all away, so the detection fails, which also means that "fma" tests are failing on Apple M1/M2 in weird corner cases 🙃

#OpenCL CTS on #rusticl on #asahi

Pass 2691 Fails 5 Crashes 0

I really should fix those two remaining bugs...

I'm currently looking into what's the best way to support SVM/USM in #rusticl and one thing I'm wondering about is, if there are any drawbacks doing:

mmap(some_chosen_address, ram_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, 0, 0);

and reserve a lot of virtual memory, and then suballocate SVM allocations out of this region with "PROT_READ | PROT_WRITE" and "MAP_FIXED"?

Alternatively, I was considering allocating smaller heaps on demand.

soo.. apparently the broadcom VC4+ GPUs (the ones used in raspberry pis and stuff) do not support format-less image writes, sooo.. supporting OpenCL images in #rusticl on that hardware will be a bit "difficult", because it needs to be handled within the kernel...

I should probably check out how other drivers are handling this, because either I'm missing something here or some other vendors are kinda in the same situation (not for all hardware, probably just older GPUs).

I wonder what should I focus on next quarter.

I'm mildly leaning towards proper SVM/USM support in #rusticl, because that's also required by more and more software (e.g. AdaptiveCPP)

Soo. the initial set of #rusticl enablement patches for the raspberry pi4 and newer are merged and will be part of mesa 24.2 (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25362)

It doesn't support profiling and images yet, but it's stable enough to pass around 97% of the OpenCL CTS

Of course there will be bugs, so any kind of testing will be appreciated.

In the meantime I'll try to get images supported.

uhh, so a few days ago I found out, that passing structs by value in #rusticl through OpenCL C or SPIR-V in fact doesn't pass the argument by value.

Turns out we don't handle the SPIR-V "ByVal" Function Parameter Attribute...

this might explain a few bugs I've seen in the past...