Zink GL-Over-Vulkan Now Supports Conditional Rendering - Stepping Towards OpenGL 3.0

[polarathene]

(Zink main developer here)

Interesting that it could still be used by NV if they take interest and do that extra work.

I suppose that'd also apply to other vendors like in the ARM space where GPU drivers may see limited development/support? They just need to provide a good vulkan driver (and DRI2?) and then could leverage OpenGL via Zink?

Or is this primarily only meant to be a compatibility layer for older software, sort of like WINE but just for graphics API? Would it enable KDE Plasma kwin to use vulkan?(I guess there isn't any benefit in doing so though if it's not using vulkan directly)

Thanks for working on Zink!

[hvis]

Thanks for the correction!

[oiaohm]

I suppose that'd also apply to other vendors like in the ARM space where GPU drivers may see limited development/support? They just need to provide a good vulkan driver (and DRI2?) and then could leverage OpenGL via Zink?

That would be a usage case. Bit broader than that.

Or is this primarily only meant to be a compatibility layer for older software, sort of like WINE but just for graphics API? Would it enable KDE Plasma kwin to use vulkan?(I guess there isn't any benefit in doing so though if it's not using vulkan directly)

Not really. Remember Zink in the mesa3d group the backwards compatible are the same no matter what.

There is a question that need to be answered that can only be answered by implementing zink.

How well does zink perform compared vendor particular opengl for a vulkan supporting gpu?

In cases where zink performs better you would not use the vendor particular opengl of course.

I see zink as setting a base line for how well vendor particular opengl drivers for GPU have to perform in compare to their vulkan driver. Zink will define the max tolerable overhead on opengl vs vulkan and this will be for Nvidia, amd and intel.

Of course zink could result in some hardware vendors doing vulkan only drivers and use Zink for opengl in time. Someways this still will be better than closed source opengl libraries that have really strange quirks all over them that you get from some embedded vendors. vulkan at this stage has less for those implementing a vulkan driver to screw up.

[cesarcafe]

One shocking thing here is that in the future Zink might be able to support on the Mac OpenGL versions newer than the last supported on MacOS, by running on top of MoltenVK.

[Speedator]

@kusma: hvis had a performance question I am interested in, too.

I'm also puzzled to hear about a big performance difference. After all DXVK runs at near-native speed, and DX and OGL should be similarly powerful.

Can you estimate the loss by gallium detour compared to the direct way like DXVK does? Is it 1-2% or does it matter? And if it matters and zink is feature complete, is it possible to get rid of the detour step by step?

[pal666]

Looking forward to the day when all APIs just translate to Vulkan and manufacturers only have to write a Vulkan driver.

i'm sure at least some manufacturers will prefer faster opengl driver

[pal666]

Definitely very exciting. There will come a day when OpenGL will be removed from drivers, and things like Zink will be the only way to run older software.

your excitement stems from cluelessness. zink is gallium backend, all its opengi is gallium opengl frontend, there's no other opengl in modern mesa opengl drivers. so by removing it you will remove opengl part of zink.

[pal666]

DXVK runs at near-native speed

for some definition of near

[oiaohm]

for some definition of near

DXVK works out somewhere between 20 slower to 20 percent faster than on windows using dx11 when on wine. Yes the 20 percent faster has triggered the ban hammer on some games so has has the 20 percent slower.

https://flightlessmango.com/benchmarks/fZu1cv9QVcU

This is the 20 percent slower this is AMD GPU. Please note this is one of the rare benchmarks where they run dxvk on windows as well as Linux so you get to see that the lot of the overhead is in fact in the dx11 to vulkan translation. In fact windows falls out side 20 percent slower if you put dxvk on it.

https://flightlessmango.com/benchmarks/PqwIAd6zmyc

Please note vulkan vs vulkan benchmarks for AMD cards normally show vulkan slower Linux than Windows so it kind of odd that windows running dxvk is getting it head handed to it by Linux versions.. You have to ask how close they would be if vulkan on Linux and Windows was in fact equal performing.

https://flightlessmango.com/benchmarks/V2_LlSaYNUo

Here is the fun 20 percent faster NVidia. Yes Vulkan under Linux from Nvidia is faster than Windows and this results in DXVK being faster than windows when used with wine with a nvidia card. Please note Nvidia is only roughly 5% faster in vulkan under Linux than windows. Yet you are seeing a 20 percent advantage in dxvk but we don't have a windows running dxvk here. It would be stupid if dxvk on windows with Nvidia turns out to be faster than using the native dx11.

So pal666 so yes it currently 20%+/- of native windows. With a decent percentage of that cause in what the heck the native vulkan driver is. Near windows performance is kind of a valid claim. Nvidia dxvk on wine exceeding windows performance 20%, AMD dxvk on wine currently losing by 20% to windows. Driver optimisations on the AMD side could see Dxvk beat windows every single time on wine.

[pal666]

DXVK works out somewhere between 20 slower to 20 percent faster than on windows using dx11 when on wine. Yes the 20 percent faster has triggered the ban hammer on some games so has has the 20 percent slower.

when dxvk is faster than driver, driver can do same thing and become even faster, i.e. it's just a slow driver(if it's not "faster by skipping some parts of rendering"). when driver is faster, dxvk can't do anything because its overhead is unavoidable