Zink Is Moving Closer To OpenGL 3.0 Support Over Vulkan

[archsway]

Why would using Vulkan as intermediate API be inherently slower than using Gallium3D? Neither goes directly from OGL to native, and Vulkan is not higher level.

I'm not sure how OpenGL->Gallium3D->Vulkan->driver could be faster than OpenGL->Gallium3D->driver.

[betam4x]

Only if you don't mind having (in some cases massively) lower performance. Such layers will never be as fast as a native implementation.

If DXVK is any indication, that is not necessarily the case. Depending on your hardware and software, DXVK on Linux/Wine can be faster than native DirectX 11 on Windows. Furthermore, DXVK on WINDOWS can be faster than DirectX 11. Alot of it comes down to the game, the ability to multi-thread, the core count of the CPU and number of execution cores on the GPU, the available vs used VRAM, etc.

On my system I get around 20-30% faster performance on GTA V for instance, and several other titles either match or exceed (by small amounts) Windows/DX11 performance.

EDIT: Though I do agree I don't see this project going very far unless they find a way to utilize threading to speed up OpenGL rendering.

[Britoid]

I'm not sure how OpenGL->Gallium3D->Vulkan->driver could be faster than OpenGL->Gallium3D->driver.

You're somehow implying each layer is adding some kind of performance overhead.

They shouldn't add any, any performance slowdown is a bug.

[smitty3268]

You're somehow implying each layer is adding some kind of performance overhead.

They shouldn't add any, any performance slowdown is a bug.

The vulkan layer has less context available to optimize things than the gallium layer does. Zink has that context, and will try to generate vulkan calls that are as optimized as possible, but it will never be entirely optimal the way that a native call directly to the hardware will be.

At least not in all cases. For example, sometimes certain things are slow on certain hardware. A native OpenGL driver can go to great lengths to try to avoid such instructions on that hardware, while Zink is just generating standard Vulkan and won't know to avoid the slow calls. By doing the calls in Vulkan, it may explicitly require the vulkan driver to do the slow instructions, rather than allowing the driver options to choose some workaround that would end up being faster.

[You-]

it would be interesting to see this added to mesamatrix.

As for performance, I suspect the performance difference to be greater for the OpenGL1.x/2.x than later as those were generally mapped to fixed hardware functions and any intermediate layer would be slower than direct access. For Open GL3.x+, it will be interesting to see where they end up.