#rusticl — Public Fediverse posts

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

Implemented enough `usm` in #rusticl that AdaptiveCPP runs.

Tried out some tests, but it seems like some of the OpenCL paths are slightly broken (as it e.g. crashes also on the Intel stack).

Not sure I'm in the mood to fix those bits, but at least now I know how much of USM is needed to run it, which.. isn't a lot tbh.

@karolherbst any idea if it might be possible to get rustICL running on the NV jetsons?

@never_released was testing a fluid dynamics code via Pocl and seeing what looks to me like a poorly optimized compiler doing a ton of register spilling.

Code in question is FluidX3D from @ProjectPhysX

#opencl #rusticl #jetson #HPC

@trafotin WHELP, turns out Resolve 18.6.5 is broken on #AMD cards using #ROCm or #RustiCL at the moment and these is nothing we can do but wait for Black Magic to fix it...

half the fails is really just v3d not supporting PIPE_CAP_QUERY_TIMESTAMP yet, which #rusticl relies on for even profiling.

Everything else is just random stuff, like not supporting unaligned load/stores yet, some arithmetic precision fails and random other stuff

I think I've tracked down the last big issue 🙃

The driver replaced the backing buffer object of a host mapped memory object causing random faults and inconsistency issues.

Sadly the way mapping memory in OpenCL works is pretty annoying. I fear I'll have to rework those bits in #rusticl as well, because I'm way to optimistic on some assumptions. And I'll also have to fix contexts with multiple devices while at it.

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

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

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

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

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

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!

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.

#Rusticl + #radeonsi works with #hashcat! The dictionary mode at least.

Trying to use brute force fails on the self test.

Still better than clover, which makes the GPU hang up so badly I can't even turn off the computer.

This is awesome cause this #APU (#Ryzen 2400G) is not supported by #rocm. Rusticl is the best #opencl I can get right now.

so uhm... I think the next big thing for #rusticl would be to get SVM up and running on #Intel and #radeonsi and I already have a plan for Intel 🦀

And that would essentially give us proper CUDA/HIP and SyCL support

uhh, seems like enough random stuff landed and now the #rusticl #radeonsi MR only has seven patches on it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19232

so close :3

So close to add support for `cl_khr_image2d_from_buffer` in #Rusticl

Antonio doing an #EVoC internship program has done so much great work on this!

This is also required to get Davinci Resolve running with #Rusticl! Well.. it also needs cl_khr_gl_sharing, but that's also already being worked on.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378

🦀 🦀 🎉 🦀 🦀

So close to add support for `cl_khr_image2d_from_buffer` in #Rusticl

Antonio doing an #EVoC internship program has done so much great work on this!

This is also required to get Davinci Resolve running with #Rusticl! Well.. it also needs cl_khr_gl_sharing, but that's also already being worked on.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378

🦀 🦀 🎉 🦀 🦀

So close to add support for `cl_khr_image2d_from_buffer` in #Rusticl

Antonio doing an #EVoC internship program has done so much great work on this!

This is also required to get Davinci Resolve running with #Rusticl! Well.. it also needs cl_khr_gl_sharing, but that's also already being worked on.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378

🦀 🦀 🎉 🦀 🦀

So close to add support for `cl_khr_image2d_from_buffer` in #Rusticl

Antonio doing an #EVoC internship program has done so much great work on this!

This is also required to get Davinci Resolve running with #Rusticl! Well.. it also needs cl_khr_gl_sharing, but that's also already being worked on.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378

🦀 🦀 🎉 🦀 🦀

So close to add support for `cl_khr_image2d_from_buffer` in #Rusticl

Antonio doing an #EVoC internship program has done so much great work on this!

This is also required to get Davinci Resolve running with #Rusticl! Well.. it also needs cl_khr_gl_sharing, but that's also already being worked on.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20378

🦀 🦀 🎉 🦀 🦀

I did a sneaky and worked on #rusticl today.

Made some progress on doing a proper clGetKernelWorkGroupInfo implementation, which is more or less needed for #radeonsi support and will help with other drivers as well.

(though there are others things I should deal with 🙃, I hope nobody finds out, otherwise I'll be in great trouble. My 🦀 🦀 🦀 will protect me!)

#Rusticl Support For #AMD #RadeonSI Driver Being Worked On

https://www.phoronix.com/news/Rusticl-RadeonSI-WIP

Original tweet : https://twitter.com/phoronix/status/1574190621350400001