Valve Developed An Intel Linux Vulkan GPU Driver

[dungeon]

Lol I don't think we asians would love your kiss . Just pay us a visit sometime when you have free time.

That "kiss" is not metter of love

Anyway I don't really live in the place that exports electronics so myself is not counted in, am I ?

Yes you are counted, everybody in the world should be

[duby229]

Again: When the hardware drivers implement SPIR-V, than the Vulkan-Library can send its stuff directly to the driver. There is no need to involve Gallium3D here.

All I can think of at this point is maybe you're mistaking gallium and TGSI as one and the same....

While it is true that gallium drivers do implement TGSI support, It will also be true that they will implement SPIR-V support as well. That'll probably be done through LLVM.

[bridgman]

Again: When the hardware drivers implement SPIR-V, than the Vulkan-Library can send its stuff directly to the driver. There is no need to involve Gallium3D here.

I think I see the disconnect here. Gallium3D is basically a standard API for hardware drivers. It's not some higher level abstraction, not something separate from the driver.

[-MacNuke-]

The hardest part will be SPIR-V support at the hardware drivers.

Again: When the hardware drivers implement SPIR-V, than the Vulkan-Library can send its stuff directly to the driver. There is no need to involve Gallium3D here.

[bridgman]

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.

Sure, but all those "global operations" (global state operations) were handled in the OpenGL state tracker (hence the "state tracker" name) and not the Gallium3D drivers anyways. Not sure I get your point other than Vulkan being different from OpenGL.

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.

Mesa I agree (that's the GLSL to IR part), Gallium3D I disagree (that's the IR to HW instruction part).

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

Sure, if you didn't have a Gallium3D driver but you did have a Vulkan driver that might be an option, but if you *do* have a Gallium3D driver already it would be really hard to justify writing a separate Vulkan driver from scratch, especially since the levels of abstraction are so similar.

[duby229]

I do not said anything about that Gallium3D drivers could not implement SPIR-V.

I said it is useless to implement Vulkan ON TOP of Gallium3D.

It's not useless. It's already does most of what Vulkan needs, it's already mature and working. The hardest part will be SPIR-V support at the hardware drivers.

EDIT: Like I already said, Vulkan looks a lot like the front end of a GPU. The whole -point- is to make future GPU designs simpler so that they can concentrate effort on capacity instead of capability.

[duby229]

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

And there is nothing wrong with implementing that support in existing drivers. Why reinvent thew wheel? Gallium already has most of the infrastructure in place that Vulkan will ultimately need.

[-MacNuke-]

There is no reason at all why gallium hardware drivers can't also support SPIR-V and they will.

I do not said anything about that Gallium3D drivers could not implement SPIR-V.

I said it is useless to implement Vulkan ON TOP of Gallium3D.

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

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