Valve Developed An Intel Linux Vulkan GPU Driver

[bridgman]

Slide 29.

"Drivers do not track state"

Yep, although slide 29 is specifically talking about resource state rather than HW state.

The statement about not *tracking* state does not mean the drivers are not involved in *executing* state commands from the application. In the case of Vulkan (and Gallium3D) state commands are given by (a) populating a state object structure and asking the driver to process it (thereby making one of the "immutable state objects" that the deck mentions, then (b) at command runtime specifying which pre-processed state objects should be used.

[duby229]

You simply do not understand the difference between a stateful API and a hardware state...

And you obviously don't understand why RAM was invented.

[-MacNuke-]

Why call it useless when it provides an API agnostic interface?

I give up... you do not understand it.

[-MacNuke-]

Slides 8, 21, 22 and 27 are the main ones. Slides 21 and 22 give examples of API calls for creating state objects. Slide 27 talks a bit about binding state objects (pipeline is basically a state object as well) to command buffers before submitting them.

https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Khronos-Vulkan-GDC-Mar15.pdf

It's not that much of an oversimplification to say that a driver basically does two things -- translate state settings to HW settings, and translate shader IR instructions to HW instructions.

Slide 29.

"Drivers do not track state"

[duby229]

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.

Why call it useless when it provides an API agnostic interface? There is absolutely nothing wrong with gallium drivers implementing SPIR-V support. Just like there is nothing wrong with them implementing TGSI or LLVMIR. Just because it's new and it hasn't been done yet doesn't mean that it can't be done or shouldn't be...

The fact is that right now gallium is providing for OpenGL, OpenCL, and Direct3D9. And will be providing Vulkan and OpenCL2.

[-MacNuke-]

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.

You simply do not understand the difference between a stateful API and a hardware state...

[bridgman]

Any links on that? I do not find anything useful in terms of state in combination with the API calls.

Slides 8, 21, 22 and 27 are the main ones. Slides 21 and 22 give examples of API calls for creating state objects. Slide 27 talks a bit about binding state objects (pipeline is basically a state object as well) to command buffers before submitting them.

https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Khronos-Vulkan-GDC-Mar15.pdf

It's not that much of an oversimplification to say that a driver basically does three things :

- translate state settings to HW settings
- translate shader IR instructions to HW instructions
- implement command submissions which combine geometry, state and shader code

[duby229]

Well eh, with Vulkan you can choose not to track the state, or even not to create the state at all (afterall you have to create the state-tracking mechnism yourself so you can use whatever to implement that, or just don't create it). While in OpenGL the state is always there and create overheads in CPU.

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.

[-MacNuke-]

Why do you think everyone should have to re-invent the wheel everytime a new API is developed? If it's in RAM, then it's in some kind of state and it doesn't matter what some marketing department says.

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.

[duby229]

That is based on the fact that driver already support Vulkan and SPIR-V. So if the driver does not support it, it would be nice to have a compatibility layer just before that right ?

It's the only use case I can think of right now anyway :P.

I assume it's being worked on already. AMD has known about Vulkan from the beginning, so I have to assume they are already working on it. It's one of thos things, when it's done is when it'll be done.