Rusticl Can Run Atop Zink Gallium3D Atop Intel's ANV Vulkan Driver

[Mani]

Why does rusticl need a gallium driver? Doesn't it convert things to SPIRV? Shouldn't any driver capable of ingesting SPIRV be able to work with Rusticl?

I may be wrong, but AFAIK Rusticl is a Gallium3D state tracker, same as there are ones for OpenGL, Gallium9, etc.
Since Zink is not a reimplementation of OpenGL over Vulkan, but actually a reimplementation of the Gallium3D API utilising Vulkan it should, in theory (with some modifications), be able to run any state tracker over Vulkan, including Rusticl.

[karolherbst]

I may be wrong, but AFAIK Rusticl is a Gallium3D state tracker, same as there are ones for OpenGL, Gallium9, etc.
Since Zink is not a reimplementation of OpenGL over Vulkan, but actually a reimplementation of the Gallium3D API utilising Vulkan it should, in theory (with some modifications), be able to run any state tracker over Vulkan, including Rusticl.

Yeah, Zink is like any other Gallium driver, just instead of talking with hardware or emulating everything in Software, it uses Vulkan to do the things Gallium expects from the driver.

[Apokalypz]

Lol add this: https://www.phoronix.com/news/HIPCL-...-OpenCL-SPIR-V
and AMD's hip version and you can have the entire compute spectrum on one system.

[karolherbst]

Lol add this: https://www.phoronix.com/news/HIPCL-...-OpenCL-SPIR-V
and AMD's hip version and you can have the entire compute spectrum on one system.

yep.. already working on it..

[StillStuckOnSI]

Can confirm that the same thing works with RADV as well. Karol and me sat down after his lightning talk and tried it.

Is there some description somewhere about how Rusticl on Zink on [vulkan driver] handles the mismatch between Kernel and Shader SPIR-V? https://twitter.com/karolherbst/stat...94530104299520 seems to cover the discrepancy in addressing models, but I imagine unstructured control flow needs to be handled (and irreducible control flow rejected)?

[karolherbst]

Is there some description somewhere about how Rusticl on Zink on [vulkan driver] handles the mismatch between Kernel and Shader SPIR-V? https://twitter.com/karolherbst/stat...94530104299520 seems to cover the discrepancy in addressing models, but I imagine unstructured control flow needs to be handled (and irreducible control flow rejected)?

most of that is already handled inside rusticl. For zink the kernel passed in already looks very much like a GL/VK shader and not that much needs to be dealt with on top of that. Zink is getting the same thing Gallium drivers do, and for them it's more or less a GL compute shader at that point.

[hamishmb]

I love this kind of thing, regardless of whether there's practical use (it seems so in this case though).

When I get around to doing some more videos and posts, I'll probably put Cygwin on WINE, and nested VMs on the to-do list. Of course, Darling (WINE for macOS software) will also be there, there have been many improvements lately.

[Amaranth]

Regarding the ability of using Zink for non top-of-the-line Vulkan drivers and hardware (i.e. most ARM SOCs like the mentioned PowerVR hardware), seeing the current requirements of Zink in terms of what is required by both the vulkan driver and the hardware (see Mesa documentation) I find it incredibly hard that Zink can be used for anything other than new (desktop targeted) hardware (i.e. intel, nvidia, amd).

Compare the list of requirements with what is exposed in Vulkan GPU Info, for example for a Mali G52 for which the Panfrost driver exposes OpenGL 3.1, Zink is unable to provide even OpenGL 3.0 for the lack of conditional rendering. For an Adreno 660, which the Freedreno exposes OpenGL 3.3 Zink is unable to provide OpenGL 3.2 for lack of shaderTessellationAndGeometryPointSize.
And, yes I know, developers should test for features instead of versions, and that probably means that you can get more mileage from Zink with respects to native OpenGL drivers.

Understand that I'm not criticising the work put in by Mike in both Zink and Mesa, I truly think he's doing amazing work, work that has tons of uses (validation, new hardware enablement, etc). I'm just saying that (existing) mobile GPUs, due to the difference in target use-cases, is not the kind of hardware that is best served by Zink (unless Mike decides to write even more super good code that would help) and is naive on our part to expect so.

Some of this may be solved by the Vulkan drivers exposing the needed functionality. Sometimes the GPU can do it or you can "emulate" it well enough but that's just not done in the driver yet. Some of this may also be solved by adding alternative (likely slower) paths in Zink. I suspect some of it is relying on OpenGL 4.x features to simplify implementing OpenGL 2.x features, stuff in Mesa does that kind of thing a lot. But then of course for some of it you just won't get OpenGL 3.x or 4.x on a given GPU even if you have most of the functionality from those that people care about. That's where you need to rely on feature/extension testing instead, as you mentioned.