3 ms·
> 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 missi
by johntb86 4y ago
> 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).
- ahartmetz 4y agoHm. 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?
- gpderetta 4y agoIt 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.
- johntb86 4y agohttps://lwn.net/Articles/768410/ 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.