Zink OpenGL-On-Vulkan Now Works Atop NVIDIA's Linux Driver

[oiaohm]

So we have DX9/10/11/12 over Vulkan, now we also have OpenGL over Vulkan.

Do we even need DX9, 10, 11, 12 and OpenGL anymore, since we have Vulkan now?

Yes and no do remember that wrapping over Vulkan does add overhead. So native DX or Opengl done well should be faster.

What use does Valve have for this? I suppose I get the value of Zink in that it would allow a hypothetical new graphics hardware vendor to make a Vulkan driver only and skip OpenGL entirely. But Nvidia already has OpenGL support, so...
unless it's just to have another option in case Nvidia's implementation isn't doing what it is supposed to.

The answer is Nvidia opengl implementation does not work with XWayland yet and there was no roadmap when Valve got involved with Zink for when it would. So Nvidia so does work with Valve developed gamescape that gives the ability to scale applications generic GPU neutral way other than Nvidia on Linux.. That is problem one Nvidia is broken crap with Wayland.

Also you old games that Valve wishes to keep on selling that were developed by third parties has that were built for opengl running on particular cards with those cards unique quirks in opengl implementation. Of course these games valve does not have source code for so you cannot fix them that way. Having to go begging to Opengl vendors to add quirks is not good either for valve. Take a old problem game make a custom opengl that matches what it needs and somehow have it accelerated is the problem space you have here. OpenGL over vulkan and for these old games on modern hardware 70% overhead is more than tolerable due to how many times faster the CPU/GPU are today compared to when they were made. This second reason also why Valve is interest in dxvk and wine because these allow Valve to keep on selling DX games that no longer work on Windows 10. If program will not run for user Valve cannot legally sell it to user so valve cannot make profit from having the right distribute that application.

So valve has two reasons to be interested opengl over vulkan. The second one means to make money.

Remember Nvidia with scaling and the like is going to make it unique to their platform this means Valve has todo more testing if scaling works right with AMD/Intel and Nvidia unless they can come up with some generic solution as well. So cost saves long term are on the table for Valve to fund this work now.

[rmfx]

The reason that Valve likes and invest in Linux so much is maybe that China could ban Windows sooner than later for security reasons. And if this happens. Who is ready to serve the gaming industry for UOS? Valve.

[bachchain]

Why do they need to put in effort to support a specific driver? Isn't being driver agnostic the whole point?

[freedonuts]

Why do they need to put in effort to support a specific driver? Isn't being driver agnostic the whole point?

I know crap about drivers but the compatibility has to come from both sides. If the driver implements non-standard api or implements it a bit differently then obviously you'll need to work around that and I assume that's the case with Nvidia.

[cl333r]

I'm sick and tired of reading about translation layers built on top of workarounds to make limitations seem less bad.

[Snaipersky]

Why do they need to put in effort to support a specific driver? Isn't being driver agnostic the whole point?

Every other driver they've got working thus far has already been a part of mesa, and have lots of common code. Nvidia's proprietary driver has none of this (though dma-buf is finally becoming a thing), so this marks zink being able to stand up a gallium/opengl driver on linux without the underlying vulkan driver doing a bunch of extras for it.
This might also mean that gallium could, in time, run on windows.

[mitch074]

I'm sick and tired of reading about translation layers built on top of workarounds to make limitations seem less bad.

The rub is that OpenGL is a mess - all previous attempts to clean up the API have failed spectacularly, with vendors still implementing their proprietary extensions and quirks in standard extensions that make programming and supporting an OpenGL application a real mess - for example, both Nvidia and AMD supporting old extensions in OpenGL 4 "strict" mode eventhough they were not supposed to, but not ALL of them, and the way they behave changes depending on what you do to the card.

What Zink allows is a single, unified OpenGL implementation that's based off what Mesa does, but instead of running on this of that hardware it "only" requires Vulkan support - meaning that supporting Zink in your OpenGL app makes it so that you don't need to track each and every quirk a hardware vendor makes in their OpenGL drivers.

[boulabiar]

I just wish NVIDIA would at least provide a Vulkan memory allocator so we can drop EGLStreams for Wayland compositors...

Aren't they already supporting it here?

https://docs.nvidia.com/drive/drive_os_5.1.12.0L/nvvib_docs/DRIVE_OS_Linux_SDK_Development_Guide/baggage/group__vulkan__group.html

[iskra32]

I just wish NVIDIA would at least provide a Vulkan memory allocator so we can drop EGLStreams for Wayland compositors...

(note: am not NVIDIA user)

I think that's in the works, maybe it'll come within one of the next driver releases.

[MrCooper]

I wonder how long until zink will start beating the nvidia OpenGL driver in some benchmarks.

This might also mean that gallium could, in time, run on windows.

VMware's Windows guest OpenGL driver has been Gallium based for a decade.