Mesa 22.3 Lands New "Rusticl" OpenCL 3.0 Implementation

[unis_torvalds]

radeonsi isn't opengl, radeonsi is a gallium backend, radeonsi is also used for clover, galliumnine opengl, and even iirc, the libva backend and I think even an omx backend

It's all a little confusing to me, but I had thought that Clover implements OpenCL atop OpenGL, just like how Zink is an OpenGL implementation on top of Vulkan, hence the name CL + Over + (GL).

In the diagram below, it depicts radeonsi as an OpenGL library (API?) which is adjacent/analagous to the older OGL implementation and the Vulkan one.

If all this is the case, it would explain why radeonsi is required by clover. But in theory couldn't you have a standalone OpenCL API which talks to the device drivers directly, without any translation to Vulkan/OpenGL? Isn't that the point of OpenCL as a language?

[Tian]

AFAIK it **only** works with Intel (i)GPUs ATM.

Good, this is the kind of gpus I was referring

[unis_torvalds]

couldn't you have a standalone OpenCL API which talks to the device drivers directly, without any translation to Vulkan/OpenGL?

This graphic suggests that yes you could, which to my understanding means bypassing radeonsi.

[Quackdoc]

It's all a little confusing to me, but I had thought that Clover implements OpenCL atop OpenGL, just like how Zink is an OpenGL implementation on top of Vulkan, hence the name CL + Over + (GL).

In the diagram below, it depicts radeonsi as an OpenGL library (API?) which is adjacent/analagous to the older OGL implementation and the Vulkan one.

If all this is the case, it would explain why radeonsi is required by clover. But in theory couldn't you have a standalone OpenCL API which talks to the device drivers directly, without any translation to Vulkan/OpenGL? Isn't that the point of OpenCL as a language?

sadly I cannot see the picture too low quality.

but Gallium is a middle man. radeonsi is the backend for gallium. and opengl is a frontend
it goes statetracker (the front end)-> gallium -> gpu-code (the backend) so to put that into perspective

OGL -> Gallium -> Radeonsi

you can replace radeonsi with any of the (compatible) drivers
OGL -> Gallium -> Iris
OGL -> Gallium -> zink -> vulkanDriver
OGL -> Gallium ->virgl -> VMHost

likewise you can replace OGL with any of the compatible statetrackers

OGL -> Gallium -> Radeonsi
Clover -> Gallium -> Radeonsi
Gallium nine -> Gallium -> Radeonsi

That being said, just because their is a front and and a backend, doesn't mean you can just combine any and expect them to work out of box, some example of things that work and don't work.

D3D10UMD -> Gallium -> LLVMPIPE : GOOD
D3D10UMD -> Gallium -> Radeonsi : NO GOOD

Rusticl -> Gallium -> LLVMPIPE : GOOD
Rusticl -> Gallium -> Iris (intel) : GOOD
Rusticl -> Gallium -> radeonsi : NO GOOD (yet)

in very simplified terms, all gallium does is be a middle ground of sorts that helps you port drivers from one thing to another. it doesn't "just work" because you have a front end in a backend, you still have some extra work to do. sometimes a lot, sometimes not a lot.

[DanL]

it doesn't "just work" because you have a front end in a backend, you still have some extra work to do. sometimes a lot, sometimes not a lot.

It sounds like a great opportunity for a job posting at AMD. It's like the time that AMD hired Tom Stellard to work on Clover.

[unis_torvalds]

[...] in very simplified terms, all gallium does is be a middle ground of sorts that helps you port drivers from one thing to another.

Wow thank you for taking the time to explain that! This helps me understand a bit better, but sadly means I'll have to wait longer for mesa OCL support for my Vega card
I guess this is what Michael meant when he wrote: "The Gallium3D driver compatibility with Rusticl currently appears limited" in the original article.

For the record here's that image full rez.

[ArchLinux]

What do you not agree with?

That truly this news is what happened.

Oh. Well, in that case, let's scrap the whole thing. Thanks for your vital input.

Thank you.

Then you need to be really fast with upstreaming your better solution bevor rusticl has time to settle in.

I do not agree.

[Quackdoc]

Wow thank you for taking the time to explain that! This helps me understand a bit better, but sadly means I'll have to wait longer for mesa OCL support for my Vega card
I guess this is what Michael meant when he wrote: "The Gallium3D driver compatibility with Rusticl currently appears limited" in the original article.

For the record here's that image full rez.

It sounds like a great opportunity for a job posting at AMD. It's like the time that AMD hired Tom Stellard to work on Clover.

as far as I am aware, there is a good amount of interest in getting radeonsi working. which is very good since clover is, quite honestly crap, and is on it's deathbed, rusticl is much better in my testing, albiet in software only obviously, since I have a radeon card.

[oleid]

Is it just me or was rusticl developed really fast?

[mdedetrich]

I do not agree with this.

Your complaint has been noted. Thank you for your time.