Valve Developed An Intel Linux Vulkan GPU Driver

[dragorth]

I am under the impression that as far as Gallium (e.g TGSI) was concerned it doesn't know anything at all about SPIR-V. SPIR-V will be implemented via LLVM and all the hardware drivers will then be able to use it. So in that case a Vulkan state tracker can function on gallium and SPIR-V will be driver dependent.

It just doesn't make any sense to build different driver platforms for every different API. Gallium3d was made to resolve that problem.

In this case, it does make sense. First, and this is important, Vulkan does not have state. So implementing it on top of a state tracker does not make sense. Developers will create state in their applications, so you could implement a Gallium3D on top of Vulkan, but not the other way around.

I don't think you know exactly what Gallium3D actually is.

So, Vulkan is a direct API to the GPU. It is a basic "do this GPU," "Yes, Master" relationship. It is "low-level" in that it directly maps to the hardware, with very thin abstraction layer. So it sits directly above the driver that implements it. It is a stateless api in both practice and fact. It is at the level of "Turn left, then right, then jump."

OpenGL is a graphics API. Notice the difference. OpenGL is a model of a graphics system, that just happens to include a GPU today. It has a large number of extensions/patches that allow it to control the GPU better than when it started. It has an extension language to control the compute units that were never even thought of when it started. And it had as a design goal to be so stable that they required this language to be error checked at runtime, every time.

Vulkan is just the control structure of this low-level system. It allow the application to create state as needed. The application has to do the setup of which order to dispatch to the GPU, how to handle different queue strategies and so forth.

SPIR-V is the actual workhorse of these two, doing the actual work on the GPU, as well as interoperating with all the ISV chips. It serves the same purpose as Gallium3D's TGSI. And that is it. That's all it does. It simply exists to be a target for front ends to optimize for.

However, Vulkan requires any compliant driver to ingest SPIR-V. Now, Gallium3D's front end can target Vulkan. And is designed to do exactly that, along with whatever other backend the driver implements.

Vulkan should look familiar, because in a way, it is the bottom of the Gallium3D stack. But it deliberately leaves the top of the stack to developers to implement. So You can implement OpenGL, or DirectX 11/10/9 or Gallium3D. But, you can also implement your own stack on top, custom built for your particular use case.

It simplifies the model that Gallium3D currently uses by requiring SPIR-V be ingested by the drivers directly, as currently each driver requires a specific version of a secondary IL created for each driver. It allows GPGPU to target the same infrastructure as the graphics pipeline, providing more flexibility from the entire system.

[bridgman]

In this case, it does make sense. First, and this is important, Vulkan does not have state. So implementing it on top of a state tracker does not make sense. Developers will create state in their applications, so you could implement a Gallium3D on top of Vulkan, but not the other way around.

Actually I think Vulkan handles state the same way as Gallium3D -- rather than having only one state and issuing commands to change it, you create state objects (letting some of the translation to HW specific settings happen early) and then bind the state objects as needed. The binding mechanism in Vulkan seems a bit different from the one in Gallium3D which might be a problem, but I don't think you can dismiss Gallium3D with a simple stateful/stateless argument.

Vulkan should look familiar, because in a way, it is the bottom of the Gallium3D stack. But it deliberately leaves the top of the stack to developers to implement. So You can implement OpenGL, or DirectX 11/10/9 or Gallium3D. But, you can also implement your own stack on top, custom built for your particular use case.

Not sure what you define as "the Gallium3D stack" but at first glance Vulkan seems fairly similar to the top of the pipe driver, ie one step down from the top and two steps up from the bottom.

It simplifies the model that Gallium3D currently uses by requiring SPIR-V be ingested by the drivers directly, as currently each driver requires a specific version of a secondary IL created for each driver. It allows GPGPU to target the same infrastructure as the graphics pipeline, providing more flexibility from the entire system.

AFAIK the Gallium3D drivers are already ingesting multiple IRs, in the sense that Tom passes LLVM IR directly into the r600 and radeonsi drivers for OpenCL.

[duby229]

I do understand the intentions of gallium, though you're correct that I don't have a funtional understanding.

The thing about Vulkan that I understand most clearly is that it was designed to be the "front end" of a GPU. So that future hardware generations can concentrate on packing more performance into a die rather than packing functionality into a die. There is no need to develop a hardware front end when clearly Vulkan was -made- to fill that role. That doesmn't mean that Vulkan can't work on existing hardware architectures, it just means that driver developers will need to code around existing hardware front ends. And that is exactly the strength that gallium3d provides.

As a state tracker Vulkan wuldn't need to care about SPIR-V or TGSI or LLVMIR, etc. It will be entirely up to the hardware driver to implement that functionality. That's the strength that gallium brings to the table. It was the whole point of it's invention anyway.

[-MacNuke-]

I am under the impression that as far as Gallium (e.g TGSI) was concerned it doesn't know anything at all about SPIR-V. SPIR-V will be implemented via LLVM and all the hardware drivers will then be able to use it. So in that case a Vulkan state tracker can function on gallium and SPIR-V will be driver dependent.

No. Just No and simply... No.

1. SPIR-V ist driver-independant
2. Vulkan has no state (for the 100000 time in this thread)

It just doesn't make any sense to build different driver platforms for every different API. Gallium3d was made to resolve that problem.

And Vulkan resolved the need for Gallium3D.

[-MacNuke-]

AFAIK the Gallium3D drivers are already ingesting multiple IRs, in the sense that Tom passes LLVM IR directly into the r600 and radeonsi drivers for OpenCL.

But why should one put the SPIR-V code through the Gallium3D Stack when you can send the SPIR-V code directly to the driver?

[duby229]

No. Just No and simply... No.

1. SPIR-V ist driver-independant
2. Vulkan has no state (for the 100000 time in this thread)



And Vulkan resolved the need for Gallium3D.

How can it not have a state? If it's in some kind of memory somewhere it's in some kind of state. It's the whole reason why the harvard architecture was invented. It's the whole reason for RAM.

[duby229]

But why should one put the SPIR-V code through the Gallium3D Stack when you can send the SPIR-V code directly to the driver?

The SPIR-V code will be going directly to the hardware driver. It's the only thing that needs to care about it.

[-MacNuke-]

How can it not have a state? If it's in some kind of memory somewhere it's in some kind of state. It's the whole reason why the harvard architecture was invented. It's the whole reason for RAM.

Your Application has a state, yes. But not the API...

If you bind a texture in OpenGL, set a light, etc., all your following draw calls will use this texture and this light. There is your state... transparent for the application. Pure OpenGL state.

Vulkan has nothing of it. The driver only has to manage the memory of your GPU (following the application requests) and execute the SPIR-V code. No state.

The SPIR-V code will be going directly to the hardware driver. It's the only thing that needs to care about it.

And Gallium3D does what?

Sending code to the driver is the work of the Vulkan-Library. Why should one send the code to the Gallium3D interface instead of directly to the driver?

[duby229]

Your Application has a state, yes. But not the API...

If you bind a texture in OpenGL, set a light, etc., all your following draw calls will use this texture and this light. There is your state... transparent for the application. Pure OpenGL state.

Vulkan has nothing of it. The driver only has to manage the memory of your GPU (following the application requests) and execute the SPIR-V code. No state.



And Gallium3D does what?

Sending code to the driver is the work of the Vulkan-Library. Why should one send the code to the Gallium3D interface instead of directly to the driver?

Unless you plan on making all of you API calls from a binary on the HD and only from that binary on that HD, then it's in some kind of state. If you can make a memory dump and read it, then it's in some kind of state.

I don't think you understand how gallium works.

[-MacNuke-]

Unless you plan on making all of you API calls from a binary on the HD and only from that binary on that HD, then it's in some kind of state. If you can make a memory dump and read it, then it's in some kind of state.

This has nothing to to with the work of a state tracker.

I don't think you understand how gallium works.

And I think you do not understand how graphic APIs work.