Valve Developed An Intel Linux Vulkan GPU Driver

[ElectricPrism]

█▀▀░█░█░█▀█░█▀▀░█▀█
▀▀█░█░█░█▀▀░█▀░░█▀▄
▀▀▀░▀▀▀░▀░░░▀▀▀░▀░▀
█▄░▄█░█▀▀░█▀▀▀░ █▀█
█░█░█░█▀░░█░▀█░█▀▀█
▀░▀░▀░▀▀▀░▀▀▀▀░▀░░▀
█░░█░█░▀▀█▀▀░█▀█░ █▀█
█░░█░█░░░█░░░█▀▄░█▀▀█
▀▀▀▀░▀▀▀░▀░░░▀░▀░▀░░▀
█▀▀░█▀█░█░█▀▀
█▀░░█▀▀░█░█
▀▀▀░▀░░░▀░▀▀▀
░░░░░░██▄
░░░░░░█░█
░░░░░█░░█
█▄▄▄█░░░██
█░░ Valve ░░░█
█ THANK YOU░█
█░░░░░░░░░░█
█░ And Give ░░█
█░ me one ! ░░█
████████████

[Prescience500]

I can't wait to actually see what the open source graphics driver developers have to say about how they will proceed.

[ahlaht]

You misunderstood what the person in the reddit thread you linked was explaining. Compiling your shaders outside the driver and then passing it into Vulkan instead of SPIR-V via a vendor extension means that all guarantees are not governed by the Khronos standard anymore but by the vendor writing the extension instead. What a driver does inside the driver after you passed in standard SPIR-V is completely unrelated to that. It could translate it to TGSI, then to NIR, then to Arabic poems and back to LLVM before emitting the hardware specific machine code. The driver would still have to pass all SPIR-V conformance testing.

Thank you. I was just about to ask.

Since GPUs do not run SPIR-V natively some kind of translation layer must always exist in between.

[Ancurio]

The driver that Valve/LunarG created is 100% from scratch in terms of userland implementation and uses the DRM interfaces with some modifications.

http://www.reddit.com/r/linux/comments/2y1wbk/valve_developed_an_intel_linux_vulkan_gpu_driver/cp6mexg

Translating from SPIR-V to whatever format is most useful for the driver doesn't sound like a good idea, since that means you throw conformance out the window.
http://www.reddit.com/r/linux/commen...driver/cp6opom

You misunderstood what the person in the reddit thread you linked was explaining. Compiling your shaders outside the driver and then passing it into Vulkan instead of SPIR-V via a vendor extension means that all guarantees are not governed by the Khronos standard anymore but by the vendor writing the extension instead. What a driver does inside the driver after you passed in standard SPIR-V is completely unrelated to that. It could translate it to TGSI, then to NIR, then to Arabic poems and back to LLVM before emitting the hardware specific machine code. The driver would still have to pass all SPIR-V conformance testing.

[blackout23]

That's exactly the position that TGSI takes in the current Gallium drivers, though. The LLVM IR portion is inside the driver stack, not directly above it like TGSI is.

SPIR-V is the compile target for tools and high-level languages. There's an assumption there that the drivers will be free to translate it into whatever format is most useful for them internally to get it going on their hardware.

The driver that Valve/LunarG created is 100% from scratch in terms of userland implementation and uses the DRM interfaces with some modifications.

http://www.reddit.com/r/linux/comments/2y1wbk/valve_developed_an_intel_linux_vulkan_gpu_driver/cp6mexg

Translating from SPIR-V to whatever format is most useful for the driver doesn't sound like a good idea, since that means you throw conformance out the window.

http://www.reddit.com/r/linux/comments/2y1wbk/valve_developed_an_intel_linux_vulkan_gpu_driver/cp6opom

[smitty3268]

Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes. And then everything else is above it, with some interesting projects being able to convert to other things, such as LLVM.

http://youtu.be/EUNMrU8uU5M?t=45m3s

This is an example of how it is presented.

That's exactly the position that TGSI takes in the current Gallium drivers, though. The LLVM IR portion is inside the driver stack, not directly above it like TGSI is.

SPIR-V is the compile target for tools and high-level languages. There's an assumption there that the drivers will be free to translate it into whatever format is most useful for them internally to get it going on their hardware.

[bridgman]

Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes.

Not sure if it's messed up, or just not doing a good job of differentiating between the Vulkan driver itself (which accepts SPIR-V) and a pre-existing HW driver layer such as Gallium3D on which the Vulkan driver might be built and which already has an internal shader compiler IR which is neither SPIR-V nor LLVM IR.

[duby229]

I guess there are two main options :

1. Have the Vulkan state tracker translate SPIR-V into TGSI before passing it to the Gallium3D driver

2. Extend the Gallium3D API definition so that SPIR-V shader code can be accepted in addition to TGSI, allowing the Vulkan state tracker to pass SPIR-V directly to the driver. This could use a SPIR-V to TGSI translator inside the driver, or could convert SPIR-V directly to an IR already being used internally to the driver, eg LLVM IR for radeonsi.

Option 2 has more flexibility in the sense that it would also be convenient for adding SPIR-V support to the clover OpenCL state tracker.

In addition to this, Vulkan API calls would need to be mapped onto Gallium3D API calls, which might require a tweak to the Gallium3D API for best efficiency (don't know if anyone has looked at things like granularity of state object definitions to see how well they align).

Option 2 is the one I personally hope will happen.

[dragorth]

The big difference beween LLVM IR and SPIR-V as far as I know is that LLVM tools can work on LLVM IR but not on SPIR-V. Tom can comment more on how things worked out, but we picked LLVM IR because of the tools (optimizing passes etc..) that it came with not because we thought it was the ideal IR for our shader compiler in an absolute sense.

Unless I'm missing something, replacing LLVM IR with SPIR-V as the driver-internal IR would require that we re-implement (or at least fork and modify) all of the LLVM tools we use today, which more or less negates the benefits of using LLVM in the first place. It seems more likely that SPIR-V would replace TGSI, although there's been less discussion of that than I expected.

Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes. And then everything else is above it, with some interesting projects being able to convert to other things, such as LLVM.

http://youtu.be/EUNMrU8uU5M?t=45m3s

This is an example of how it is presented.

[bridgman]

The big difference beween LLVM IR and SPIR-V as far as I know is that LLVM tools can work on LLVM IR but not on SPIR-V. Tom can comment more on how things worked out, but we picked LLVM IR because of the tools (optimizing passes etc..) that it came with not because we thought it was the ideal IR for our shader compiler in an absolute sense.

Unless I'm missing something, replacing LLVM IR with SPIR-V as the driver-internal IR would require that we re-implement (or at least fork and modify) all of the LLVM tools we use in the shader compiler, which would largely eliminate the benefits from using LLVM in the first place.

It seems more likely that SPIR-V would replace TGSI, although there's been less discussion of that than I expected.