Core Compute Shader Support Under Review For Gallium3D

[phoronix]

Phoronix: Core Compute Shader Support Under Review For Gallium3D

Samuel Pitoiset sent out a set of 17 patches today that add the core of the compute shaders support to the Mesa state tracker as needed by Gallium3D drivers...

http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Compute-Shader-RFC

[gururise]

Wondering out loud if Intel will ever switch over to Gallium 3D? It seems almost a waste of work to redo everything twice (once for Intel, and once for Gallium 3d).

[smitty3268]

Wondering out loud if Intel will ever switch over to Gallium 3D? It seems almost a waste of work to redo everything twice (once for Intel, and once for Gallium 3d).

Never going to happen now that Vulkan is the new hot thing. They'd be silly to try and rewrite their whole OpenGL driver now.

[geearf]

Well they could use the one written by Lunar instead of rewriting it from scratch (assuming it was a good base).

[zanny]

Never going to happen now that Vulkan is the new hot thing. They'd be silly to try and rewrite their whole OpenGL driver now.

Except there is going to be a Vulkan state tracker for Gallium, and there will be an Intel Vulkan driver developed by LunarG. One will be shared by almost all GPUs, and once again, the other is Intel-only.

Gallium is not just OpenGL. Its not even just GPU programs. It will almost certainly be doing SPIR-V -> TGSI -> Winsys, while Intel is doing SPIR-V -> their DRI driver.

I would definitely consider that not having Gallium for Vulkan might make a bit of sense, because you are working on a much reduced complexity layer - SPIR-V is meant to be similar to LLVM-IR - but my understanding is that the community is trending towards wrapping Vulkan into the Gallium stack rather than having SPIR-V consumer implementations for all the DRI drivers except Intels.

Well they could use the one written by Lunar instead of rewriting it from scratch (assuming it was a good base).

Vulkan is not really designed to work like that. You are getting binaries in SPIR-V form and are just meant to translate those to machine instructions for your hardware. In the LLVM world we have LLVM frontends for C, C++, D, Rust, etc - but they all convert to LLVM-IR (aka SPIR-V, where the generators in GL space are Vulkan and OpenCL) and are then consumed by backend drivers for SPIR-V - the x86, ARM, MIPS, etc targets of LLVM.

You can absolutely do code sharing on the right side of that equation, but its not going to be nearly as lucrative as sharing as much of the stack as Gallium already does - in practice, TGSI is the SPIR-V of Gallium, with drivers consuming it through winsys and it being generated by converts from NIR and Mesa IR which are generated from GLSL. Its the difference between Python being JIT (because modern OpenGL shaders are distributed in text form) versus having bytecode like Java (which is what all the translation formats are).

Today, we have this mature implementation of translation from intermediary representation to machine code in the Gallium TGSI -> winsys layer. It is less work for all involved to develop SPIR-V -> TGSI (or the SPIR-V -> LLVM that Khronos released here: https://github.com/KhronosGroup/SPIRV-LLVM) than to have parallel TGSI -> hardware and SPIR-V -> hardware implementations.

So while you might be able to code share a bit using the LunarG driver, that requires Gallium users to develop entirely new drivers based off the LunarG source for their architectures versus just translating SPIR-V.

[duby229]

Except there is going to be a Vulkan state tracker for Gallium, and there will be an Intel Vulkan driver developed by LunarG. One will be shared by almost all GPUs, and once again, the other is Intel-only.

Gallium is not just OpenGL. Its not even just GPU programs. It will almost certainly be doing SPIR-V -> TGSI -> Winsys, while Intel is doing SPIR-V -> their DRI driver.

I would definitely consider that not having Gallium for Vulkan might make a bit of sense, because you are working on a much reduced complexity layer - SPIR-V is meant to be similar to LLVM-IR - but my understanding is that the community is trending towards wrapping Vulkan into the Gallium stack rather than having SPIR-V consumer implementations for all the DRI drivers except Intels.

Well, unfortunately it's not going to work that way. AMD's Vulkan implementation for example will run directly on top of DRI and won't use mesa at all. Chances are highly likely that LLVM will be able to translate GLSL to SPIR-V. If that outperforms mesa's own drivers it may be possible to run mesa's OpenGL implementation on top of any vendors Vulkan implementation someday.

[zanny]

Well, unfortunately it's not going to work that way. AMD's Vulkan implementation for example will run directly on top of DRI and won't use mesa at all. Chances are highly likely that LLVM will be able to translate GLSL to SPIR-V. If that outperforms mesa's own drivers it may be possible to run mesa's OpenGL implementation on top of any vendors Vulkan implementation someday.

The problem is that OpenGL is much more than just GLSL - implementing the C API is itself as much of a challenge most of the time as implementing shader language functionality, often more. If LLVM can translate shaders that alone is not even close to a full OpenGL implementation, and Vulkan itself is set to launch with only GLSL support - you will be writing the same GLSL shaders for Vulkan or OpenGL, just the Vulkan API around those shaders will be lower level and thus less complex. Khronos has stated their intention to add C++ as a language target for SPIR-V, so you can compile C++ programs to GPU shaders, but that probably won't release with Vulkan 1.0. But Vulkan 1.0 is supposed to include a GLSL to SPIR-V compiler - thats the whole point of Vulkan. Minimalist C++ based API around GLSL shaders all compiled into SPIR-V intermediary blobs to be consumed by GPU drivers.

AMD's initial Vulkan implementation is going to be proprietary, and the lack of interoperability will almost certainly require the Nouveau / Freedreno / Videocore / Lima developers to implement a Vulkan state tracker because they cannot all handle the man hours needed to implement either their own SPIR-V -> hardware compilers or LLVM -> hardware compilers. It is likely until AMD open sources theirs that most of us who care about freedom will depend on Intel's open source implementation or this community Gallium tracker if it even happens.

And I'm pretty sure the Vulkan implementation from Intel is meant to be merged into the Mesa project, in the same way their DRI driver is in the freedesktop infrastructure around Mesa. It won't be a part of the Mesa libgl implementation project, but neither are Gallium / any of the x DDX's / the DRI drivers. But they might not - Beignet is independent from Mesa, so they might go that route too. Have they made promises either way?

[pal666]

Except there is going to be a Vulkan state tracker for Gallium, and there will be an Intel Vulkan driver developed by LunarG. One will be shared by almost all GPUs, and once again, the other is Intel-only.

we have not seen vulkan spec yet. maybe it has not much to share at state tracker level. on the other hand someone can implement gallium pipe driver on top of vulkan and automatically get opengl etc support for all cards with vulkan driver, including intel

[airlied]

Except there is going to be a Vulkan state tracker for Gallium, and there will be an Intel Vulkan driver developed by LunarG. One will be shared by almost all GPUs, and once again, the other is Intel-only.

There won't be a vulkan state tracker for gallium, VK is a lot lower than gallium.

Dave.

[pal666]

i have better topic for discussion. will radeonsi make 4.2 or 4.3 for march mesa release?