Zink OpenGL-On-Vulkan Seeing Some 50~100% FPS Gains

[artivision]

If only I had a dollar for every buzzword.

Isn't D9VK faster than native then?

[eydee]

Let's remember it's mostly tested and developed on Intel stuff. 100% improvement means going from 1 fps to 2 fps.

[caligula]

Vulkan is really the best thing that happened in graphics over the past 10 years...

Now we can have dxvk and this happening too

I think many Linux users still haven't ever started a single Vulkan app.

[Guest]

Vulkan is really the best thing that happened in graphics over the past 10 years...

Now we can have dxvk and this happening too

And clvk too! Maybe we can have proper opensource OpenCL support on AMD and NVIDIA, and just show the finger to both of them.

[Guest]

Let's remember it's mostly tested and developed on Intel stuff. 100% improvement means going from 1 fps to 2 fps.

Or it could be 15 FPS to 30 FPS. You need to look at the actual FPS numbers before passing judgement, but you might be right in that the increase is dramatic only due to already low FPS.

[aufkrawall]

Isn't D9VK faster than native then?

That indeed tends to happen. While Microsoft in some cases has crippled D3D9 performance with Windows 10, it's still impressive.

[curfew]

What were the previous benchmarks? If Zink used to be three times slower, then now it is only 50% slower. If it used to be 50% slower, now it is up to 25% faster.

If you're referring to native OpenGL implementation vs. ZInc, I don't see how Zinc could ever be faster. Native implementations always use the internal graphics card API or instruction set, so when optimized properly, it will also be faster. Zinc is building atop another public API so there must be an overhead of some kind, I would guess something between 10 and 30 % at minimum.

Vulkan API is closer to metal so maybe it can be generalized that it will also be less prone to bugs. So Zinc could maybe be a viable solution for drivers that lack "proper" OpenGL implementation, something that is not broken due to bugs.

[V1tol]

If you're referring to native OpenGL implementation vs. ZInc, I don't see how Zinc could ever be faster. Native implementations always use the internal graphics card API or instruction set, so when optimized properly, it will also be faster. Zinc is building atop another public API so there must be an overhead of some kind, I would guess something between 10 and 30 % at minimum.

Vulkan API is closer to metal so maybe it can be generalized that it will also be less prone to bugs. So Zinc could maybe be a viable solution for drivers that lack "proper" OpenGL implementation, something that is not broken due to bugs.

How Zinc is different from DXVK for example? There are lots of examples when gaming on Linux is faster than super native API support in Windows. Redesigning super old API over modern graphics stack can lead to unobvious optimizations. For example, using multithreading properly without ugly external hacks.

[wertigon]

If you're referring to native OpenGL implementation vs. ZInc, I don't see how Zinc could ever be faster. Native implementations always use the internal graphics card API or instruction set, so when optimized properly, it will also be faster. Zinc is building atop another public API so there must be an overhead of some kind, I would guess something between 10 and 30 % at minimum.

Vulkan API is closer to metal so maybe it can be generalized that it will also be less prone to bugs. So Zinc could maybe be a viable solution for drivers that lack "proper" OpenGL implementation, something that is not broken due to bugs.

Not an expert here, however, OpenGL is a really old api designed for really old hardware. Hardware so old, in fact, it has changed fundamentally once Vulkan was implemented.

I find it plausible that a Vulkan based renderer could outperform a native renderer simply because the Vulkan renderer is based on a much more efficient HW path. Say for instance that a 4 field vector in OpenGL could be fitted to an 8 field vector in Vulkan so that the Vulkan calculations effectively can handle two four-field vectors at the same time. This then becomes twice as fast for some instances.

I have no clue if this is actually the case; just making the point that old APIs on new hardware are not necessarily as fast as on the old hardware.

[curfew]

Not an expert here, however, OpenGL is a really old api designed for really old hardware. Hardware so old, in fact, it has changed fundamentally once Vulkan was implemented.

Hardware has changed but OpenGL hasn't. Whatever the specification is, any implementation has to obey to even all the "stupid things" in it, too, limiting possible performance on a more capable hardware. It does not matter which so-called platform the OpenGL implementation is built on top of.

I find it plausible that a Vulkan based renderer could outperform a native renderer simply because the Vulkan renderer is based on a much more efficient HW path. Say for instance that a 4 field vector in OpenGL could be fitted to an 8 field vector in Vulkan so that the Vulkan calculations effectively can handle two four-field vectors at the same time. This then becomes twice as fast for some instances.

I don't see how any of these Vulkan-enabled optimizations wouldn't be possible also using the underlying native instructions, unless of course vendors don't care about OpenGL performance anymore and haven't bothered with it.