Valve Developed An Intel Linux Vulkan GPU Driver

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

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

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

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

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

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

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

[dragorth]

A correction.

@SSX

Intel mobile SoC are pretty expensive, what you think is much is less than 4% marketshare. The new Atom x3/x5 do not use Intel HD gfx and are not produced by Intel itself, but they are cheaper, lets wait for this years results. Btw. informer Intel often used PowerVR gfx cores for low power Atom chips.

You are correct about the Atom X3, however, both the X5 and the X7 are using Intel graphics.

Source

What many in this discussion are missing is the real reason Intel will support this heavily. The area they have traditionally struggled with is power consumption, and OpenGL's single core model, driver overhead, and required error checking create a significant load on all SOC's. Getting rid of this overhead will mean in most use cases, the SOC can stay lower clocked, using less power, and providing longer battery life. Yes, it will enable fancy games, and all of the things, but it has more than one side to the story.

Now, Intel is already a big fan of Wayland, so if a Wayland backend is created for Vulkan, and/or Android adopts it as the underlying graphics stack, then the sky is the limit for Intel.

[dragorth]

So there probably won't be a /usr/lib/libvk.so, but every game ships its own like on Windows with d3d9.dll. Which is actually cool, because that allows stuff like the ENB Series for Skyrim & Co. I'm not sure you could do the same with current OpenGL right now.



Or OpenGL 4.3 where OpenGL ES 3.1 is basically a subset of that. Both introduced compute shaders. Ivy Bridge Hardware does compute with Direct3D 11, but they never released OpenGL 4.3 drivers so in theory Vulkan should work on Ivy Bridge and newer.

A fragment of the talk is online here:
http://www.ustream.tv/recorded/59557323

John McDonald answered a question about hardware support towards the end.

Mentioned in that Ustream channel is an answer to the question of how to choose the correct GPU when writing your application. They stated that they are working on a loader library that will take care of some of the details, so there will be some sort version or incarnation of /usr/lib/libvk.so. However, you don't have to use it. They stressed they recommend its use, as we may inadvertently interact with some GPU combination that we did not think of, since it will be possible for Intel, Nvidia, AMD and others to all be in the same system, and they will take care of all of that in the loader.

[duby229]

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.