Hacker News Reader

Comment by slabity | Hacker News Reader

Can anyone explain to me the performance difference between having a native OpenGL or DX9/10/11 userspace driver vs having a Vulkan/DX12 userspace driver and using Zink or DXVK to implement the older APIs?

From my understanding, Vulkan/DX12 are APIs that are supposedly very low-level and allow fine-grain control over things like memory access, synchronization, and hardware-level optimizations (usually through the use of extensions). For OpenGL and DX9/10/11, these are basically higher-level abstractions that can be implemented on top of the lower-level APIs.

Assuming the above is accurate, what advantage do you get by having "native" OpenGL or DX9/10/11 implementations on your GPU? Is there anything Intel is missing out on by using DXVK as opposed to implementing their own implementations?

And how does Gallium3D (from the Mesa project) fit in all of this for Linux? Is that a lower-level abstraction than Vulkan?

View on HN

> Assuming the above is accurate, what advantage do you get by having "native" OpenGL or DX9/10/11 implementations on your GPU? Is there anything Intel is missing out on by using DXVK as opposed to implementing their own implementations?

One key issue is that Vulkan makes assumptions about the structure of graphics pipelines, which can make it harder to optimize the driver when an application changes a piece of state. For example, if an application changes the face culling mode, this may require recompiling the entire pipeline, which can be inefficient.

In contrast, native OpenGL or DirectX implementations allow for more flexible and efficient ways of managing state changes. For instance, they may provide hardware toggles that can be used to quickly and easily update the state without needing to recompile the entire pipeline. This can significantly improve the performance of the driver.

They're adding new VK_EXT_extended_dynamic_state extensions to allow setting state dynamically, but the extensions don't support every single random piece of hardware state, and some hardware state can be limited or weird enough that it's hard to export in any sort of generic interface. Try explaining to a user that dynamic state A only works if there's enough free internal memory that hasn't been filled up by state B + C or D + A.

Also any abstraction layer will add CPU overhead because you need to manage/allocate more objects, process state through more layers, etc. It doesn't matter in every piece of code, but processing draw calls (which can happen millions of times a second) it can add up.

> Gallium3D

Is a lower layer below OpenGL. It was originally intended to be at a similar level to D3D9, so OpenGL drivers could avoid a lot of state tracking (e.g. texture dimensions are immutable open creation). It's still higher-level than Vulkan, since memory management and synchronization implicit (at least last I checked).

Hm. If Gallium3D is in some way higher level than Vulkan, but it also allows higher performance high-level API implementations (as I believe it does), maybe that is because it's internal to Mesa so drivers can punch holes in its abstractions as needed?

https://lwn.net/Articles/768410/ has a good explanation of the differences:

> The third option, surprisingly, is Gallium3D (or simply "Gallium"), he said. He has been learning that it is basically a hybrid approach between state streaming and pre-baked pipelines. It uses "constant state objects" (CSOs), which are immutable objects that capture a part of the GPU state and can be cached across multiple draw operations. CSOs are essentially a Vulkan pipeline that has been chopped up into pieces that can be mixed and matched as needed. Things like the blending state, rasterization mode, viewport, and shader would each have their own CSO. The driver can associate the actual GPU commands needed to achieve that state with the CSO.

It is probably because Gallium3D was designed specifically to implement higher level APIs like OpenGL and D3D, so they made sure that there was an efficient mapping.

Vulkan is growing extensions specifically for that though, so in the medium term it might catch up.

One of the reasons graphics drivers are huged on windows is because since there was no way to optimize precisely with old APIs like dx9 and gl, drivers would often « recognize » the game engine running and switch to a fast path dedicated to it. That’s why there were updates so often and why you would sometimes even see « improved performance for game X » in the changelog. I guess that’s exactly what is happening here. DXVK is the « generic » driver, while their implementation is fast path for specific games.

I wonder if this tradition of game-specific driver patches has even changed with the modern APIs though. If yes we would eventually see less frequent driver updates (which doesn't seem to be the case so far).

My understanding is yes and no. In the pre DX12 era drivers often contained full replacement shaders for games sometimes. Where the OEM would hand write a replacement that worked better than what the game dev did, potentially on a GPU sku level. They would also potentially completely re-write how sections of the pipeline worked with shims for the same reasons. This was sustainable because shaders were relatively tiny (look at the limitations of DX9 shaders vs DX10+), and the pipeline relatively simple. However moving forwards to DX10+ and shader size explodes, as does pipeline complexity, and shader count. While they still did this for popular titles by special agreement, they largely switched to issuing guidance and providing tools to devs to optimize their games. But the issue persists. Writing shaders for Nvidia's warp system will potentially compromise performance on AMD, Intel etc. So OEMs still do some shims for games when performance is particularly egregious. But with DX12 and Vulkan in particular it's more about having presets for things like you'd find in NVidia control panel and a few game specific optimizations to critical paths, instead of just replacing how that game interacts with the driver completely.

I think we're seeing something related instead. AMD/nVidia have 20+ years of optimizing for specific games in their drivers. Intel doesn't. So they're using DXVK to make up for all the games they don't have the time/resources to optimize for. If this works out for Intel long-term, it would be a huge boon for all of us. It means any future competitors would be able to use DXVK to make up for the disadvantage of joining the game so late.

I think it's just bugfixes now. Instead of updating drivers, nVidia and AMD now work directly with developers to integrate the optimizations into their engines.

I think it has to be stressed that Vulkan and Direct3D 12 are still abstractions, and still do not provide direct hardware access. In some cases, their more explicit nature allows you to implement older APIs on top of them without any performance issues, but there are places where the abstractions make incompatible assumptions and it is very hard to get as good performance as a native driver can.

Reply on news.ycombinator.com