I wanted to learn Rust and I was thinking, why not implement OpenCL in it inside mesa and see how nice it would be to use Rust inside mesa.
I wish I had something to point to, but there is no documentation (I know, I am a terrible person) and no design document I've should have written or anything. Roughly I put most of the API validation inside
api/ and most of the real implementation inside
core/. Shared code, especially wrappers around mesa code live inside
mesa/. I wish I could even show some nice graphs about internal dependencies or anything. Nope, doesn't exist.
clc for compiling source code to
SPIR-V and it relies on drivers supporting
Rusticl doesn't really add anything new except
bindgen as dependencies.
clc needs the
libclc, so that needs to be installed as well.
-Dgallium-rusticl=true -Dopencl-spirv=true -Dshader-cache=true -Dllvm=true and.. that should just be it.
There is a workaround as the meson bindgen module can't deal with include paths for generated headers, so one needs to adjust a relative path pointing to the build dir.
OCL_ICD_VENDORS and point it towards the
rusticl.icd file. To run it on top of llvmpipe also set
It passes like most of the OpenCL 1.0 related CTS tests and a bunch of other ones. The CTS isn't really good at running against a specific version below 1.2. As Rusticl also reports CL 3.0 as the platform version some of the newer APIs are implemented as well. Older APIs might not be on the other hand.
support explicit local groups bigger than 1 (works with 0 already, just not when the application specifies the size)
Review the Rust code
passing the 3.0 CTS
convert to Rust 2018
A better origin story as mine is boring.
SPIRV-link bug: https://github.com/KhronosGroup/SPIRV-Tools/pull/4784
LLVM OpenCL headers expose CL extensions we don't support as they are always support for spirv targets, we need to make that optional
fix vload/vstore half function when using opencl-c-base.h: https://github.com/llvm/llvm-project/issues/55275
Add CI tests building it
Add CI tests running it on llvmpipe and/or iris
Nice to Haves:
support for 32 bit devices
compile to hw when a cl_kernel object is created and fetch work group info from the driver
support for function calling: this needs work in the backends. Inlining everything works for quite a bit of stuff (e.g. luxmark v3.1 LuxBall), but bigger kernels we might not be able to run.
Figure out why Geekbench 5 crashes
cl_khr_gl_sharing (used by multiple apps)
cl_khr_image2d_from_buffer (required by davinci resolve)
make it work with radeonsi
make it work with r600
fix luxmark v4
fix random crashes with gimp