Valve Developed An Intel Linux Vulkan GPU Driver

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

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

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

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/uploa...-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"

[-MacNuke-]

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

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

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

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

[-MacNuke-]

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

Another sentence from you that shows that you do not understand it xD

[duby229]

Another sentence from you that shows that you do not understand it xD

If it's in some kind of memory, then it's in some kind of state. That's a fact.

There is no reason at all why gallium hardware drivers can't also support SPIR-V and they will. When that support is done they will be able to use Vulkan and OpenCL2. When it happens I'll be sure to say I told you so.

[-MacNuke-]

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.

Yeah, the hardware is not stateless. But it is the application which has do deal with it (and sure, the driver has to do what the application says and handle all that stuff).

But this has nothing to do with the API itself. There are no "global operations" which influences the following commands. You put stuff into the GPU pipeline through the driver and get the results.

Also there is no need for all the compiler stuff which is in Mesa3D and/or Gallium3D. Shader will also be compiled by the application with an external compiler.

As I said. Vulkan is some kind of Gallium3D for the driver on itself. You could implement DirectX and OpenGL on top of Vulkan (like with Gallium3D).