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 :)
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.
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 
If you play with photography or LLMs on your X13s, #OpenCL for Qualcomm #Adreno 6xx and 7xx series MR is now ready. Rewrite of ops lowering needed for #Rusticl also fixes additional dEQP GL test 
for Mesa3D 24.3 release!
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30835
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
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
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
