Mesa's New OpenCL Stack "Rusticl" Nearing Formal Support For OpenCL 3.0

[karolherbst]

After years of neglect in Mesa's OpenCL efforts, I am more than cautious about RustiCL's impact. Let's wait and see how it performs and how well its compatibility with popular OpenCL software is.

https://twitter.com/karolherbst/status/1509703723253125125

But there are huge issues if it comes to compiling bigger kernels as currently we don't support function calling in backend compilers, and this can mean a lot of work as a lot of the nir code might has to be fixed if we stop assuming "everything is inlined"

[-MacNuke-]

That seems to be the case, at least according to Wikipedia:

Since near to nobody implemented OpenCL 2.x in a somewhat usable way they "restarted" OpenCL with version 3.0.

[karolherbst]

While I appreciate Micheal needs for headlines that generate clicks the bottom line is if you need compute with Image support your only two options are CUDA or buy a M1. That comes from some one that despises both NVidia and Apple. OpenCL on Linux with image support will never be a thing. There have been to many scams about it being ready or just around the corner for any one to ever take it seriously again.

check my message above this one

[karolherbst]

Huh, so "Rusticl should work for other Mesa drivers supporting the NIR intermediate representation" means:

• Beignet replacement for Ivy Bridge / Sandy Bridge devices?
• Maybe even better OpenCL performance?!
• OpenCL support for all devices powered by the *crocus* driver? (915g is the remaining Intel NIR - TGSI driver, right? So no 1st Gen MacBook OpenCL action!??! laaaaaame)

I mean like yeah, in a rush-rush-rush society these are "old" but *not* unusable. Haswell - ULT has 4EUs with the i7-4600U: but those EUs should be put in use whenever and wherever possible!

I'm personally looking forward to a less-dusty OpenCL implementation on my nice 12.5 Latitude 7240 with an i7-4600U. (with 1866MHz CL10 RAM for ever little 0.01% of performance) --- Now Vulkan just needs a little more polish...

Deffo excited!

yeah, so besides requiring NIR there are a few other things drivers need:
1. able to bind global buffers with full pointer support. Some devices can only do SSBOs, which are a little different. We might be able to get around that by just advertising such devices as 32 bit ones, but there is no fallback code for that at the moment anyway.

2. compute shaders (obviously), but the requirements are actually weaker than in OpenGL. E.g. on Nvidia Tesla (nv50) we can't really expose compute shaders, because of some minor details, but the devices are CL 1.1 compliant

3. a few gallium callbacks I depend upon, but Jason has been working on writing proper fallbacks, so drivers can just use those.

[karolherbst]

Did you test it on ppc64le? Does it work with darktable? rocm is almost impossible to compile under ppc64le thus it will be a great replacement for AMD cards on Power 9 Raptor systems.

good question. I doubt anybody did Also support for this on radeonsi is being worked on by others, but I don't think anybody got it ready to run yet.

[Quackdoc]

https://twitter.com/karolherbst/status/1509703723253125125

ohhhh, I was originally worried this was just going to be a toy but hopeful. i'm quite excited now. I realize this isn't indicative to OCL as a whole yet. but I look forward to the future.

[Michael_S]

Obligatory: that's pretty cool, but they should rewrite it in Rust.

Sorry, I couldn't help it.

[karolherbst]

Obligatory: that's pretty cool, but they should rewrite it in Rust.

Sorry, I couldn't help it.

huh, what do you mean?

[Snaipersky]

huh, what do you mean?

Meme around here is for any project to be suggested to be rewritten in rust, even if the project is already written in rust.

[Michael_S]

huh, what do you mean?

Snaipersky answered for me.