Valve Developed An Intel Linux Vulkan GPU Driver

[robclark]

Nobody is re-inventing the wheel.

Gallium3D was created, because every driver implemented a state-tracker, a shader-compiler and an internal representation of things going on.

Vulkan is simply the last step to the hardware itself. When the driver implements SPIR-V directly, than Gallium3D on itself is useless for that task. The Vulkan-Library will send the code to the driver and not to another library (like libGL).Sure you need Gallium3D to execute applications which are using OpenGL, but not for Vulkan.

Or in short. Vulkan is some kind of Gallium3D.

One way or another, I don't think supporting both a gallium pipe driver for opengl, and a vulkan driver, is a reasonable option. It's not like opengl is going away tomorrow. Unless someone steps up with an open source opengl on top of vulkan, then I think we will have to somehow implement vulkan as a stateless gallium state tracker ;-)

[robclark]

The only way to not create a state is execute directly from binary form off of the storage medium. Otherwise if it's in RAM, then it is in some state.

different definition of state..

in this context, "state" means "stateful API", ie. w/ opengl the driver is tracking state behind the scenes rather than application passing objects that describe the state.

[LEW21]

I guess some people assume Gallium3D = state tracker, and that is simply not true. Gallium3D = state trackers PLUS hw drivers PLUS winsys implementations. And, as the interface between state trackers and hw drivers is AFAIK quite similar in spirit to Vulkan, it will be probably quite easy to:
1) provide Vulkan implementation over Gallium3D drivers
2) provide Mesa's OGL API over Vulkan drivers

[Ancurio]

It seems like two people are constantly talking past each other regarding the semantics of "state". In OpenGL, you would for example set a scissor state, which is global and affects all calls thereafter until changed (so any code requiring a specific scissor setup needs to first save the old state before clobbering it), whereas in Vulkan absolutely everything is packaged into neat objects which don't affect each other. That's all the difference. It's analogous to passing the desired scissor state directly into glDrawWhatever (if that was possible in OpenGL, which of course it's not).

SPIR-V is not some magic bullet that will somehow automatically give you support for an entire API (which I feel some people are mistaking it for). It's just compiled GLSL (very simply put, of course you could write a compiler for any imaginary shader language, and I didn't mention compute kernels either), nothing more. You're not going to compile arbitrary C programs to SPIR-V and somehow have them run on the GPU. If you were to implement Vulkan on top of Gallium, you would write one generic SPIR-V -> TGSI pass since all Gallium drivers consume TGSI (I believe, or are there OpenCL exceptions?).

The presentation mentioned further clarified that you shouldn't think of Vulkan as "low level"; rather, it is a graphics API that first the design of current hardware much more closely.

[duby229]

different definition of state..

in this context, "state" means "stateful API", ie. w/ opengl the driver is tracking state behind the scenes rather than application passing objects that describe the state.

I guess I took something I know about and applied in the wrong context during this thread. I apologize for that.

One way or another, I don't think supporting both a gallium pipe driver for opengl, and a vulkan driver, is a reasonable option. It's not like opengl is going away tomorrow. Unless someone steps up with an open source opengl on top of vulkan, then I think we will have to somehow implement vulkan as a stateless gallium state tracker ;-)

About the "stateless gallium state tracker ;-)", that means using SPIR-V that the driver provides instead of TGSI right?

[bridgman]

About the "stateless gallium state tracker ;-)", that means using SPIR-V that the driver provides instead of TGSI right?

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).

[dragorth]

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).

My understanding of the intent of SPIR-V has been for it to BE LLVM-IR, only for all GPUs. Keep in mind, the idea is to get rid of the driver overhead, including converting into an intermediate language during execution. I am not saying it can't be done, I am saying it is not ideal for graphics or compute use cases.

The Unix philosophy is for each thing to do one thing well, then SPIR-R which is a direct GPU mapping going into LLVM IR to then go into the GPU seems to defeat both that philosophy and its purpose.

Keep in mind, Khronos originally wanted to use LLVM-IL for SPIR then decided against it for two reasons, the IL was always in flux and could go in a completely counter direction without them having a say, and LLVM-IL didn't map neatly into the GPU use case. So SPIR-V was design to counter those issues, meaning it is the better match to go directly to the GPU.

[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.

[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.

[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.