Zink Is Now OpenGL 3.0 Complete For Generic GL Over Vulkan

[Speedator]

If I understand correctly Zink has an extra gallium layer = more translation work. So DXVK is faster by architecture. Maybe they bypass the layer step by step to make it faster Ehen it is feature complete.

[oiaohm]

If I understand correctly Zink has an extra gallium layer = more translation work. So DXVK is faster by architecture. Maybe they bypass the layer step by step to make it faster Ehen it is feature complete.

Not that straight forwards. There are a lot of layers between gallium layer in mesa and the graphics card with native mesa opengl drivers doing optimisations and other things.

Distance between software and GPU by zink vs native driver could in fact be the same.

Its really simple to forget open source opengl drivers you are almost always using gallium anyhow. So gallium is not extra layer.

Opengl is end of life this comes important.

GLSL is not getting new features. Opengl 4.6 starts providing SPIR-V for shaders and other things.

Lets look at distance from gallium to GPU. Why because gallium is there be it a open source native opengl driver or zink so up until that point there is no difference in most cases.

Native mesa driver is going to take GLSL to NIR but there has to be a stack of optimisations performed to make it work the best on the GPU. GLSL to SPIR-V to NIR of zink looks worse until you wake up that the optimisations passes that are performed in the SPIR-V code stage will also have to be perform in the GLSL to NIR translation in the native drivers.

Zink is a very interesting question if it works well doing GLSL to SPIR-V to NIR this could reduce the complexity of maintaining a extra optimisations path. Remember Opengl 4.6 you have to support SPIR-V. This is just your shaders.

Now opengl implementations these days are multi threading a lot of stuff in background.something vulkan was designed todo well.

https://www.phoronix.com/scan.php?page=article&item=nvidia_threaded_opts

Yes it really simple to forgot these threaded optimisations these really do put a extra layer between your application and the GPU anyhow just a layer you cannot interact with or in some cases don't even have documentations on what is up to. Native opengl drivers are doing this because opengl was not designed to take advantage of multi CPU cores well.

That the problem zink may not in fact be more layers in reality. Zink may be more standard documented layers and that might be the only difference.

Yes it really simple to miss that Zink taking GLSL into SPIR-V may pick up vulkan optimisations that the GLSL to NIR code does not perform and are complex to perform. NIR feature set is not based on GLSL its in fact based on SPIR-V so NIR will extended with Vulkan/SPIR-V from now on.

Of course people will say that opengl drivers should be faster than Zink. Problem is that is not that straight forwards opengl is legacy is not how graphics GPU or CPU work any more. OpenGL being legacy means you have abstraction layers behind hide it trying to make it work on modern well. Reality if your are counting number of abstraction layers between application and GPU that are in fact there be it a modern native opengl driver for a card that support vulkan or Zink the count can be exactly the same.

Question is there any major advantage for video card vendors to share open source abstraction layer based on vulkan to convert opengl to multi threaded and modern multi threaded gpu methods? This is what zink is a prototype to ask the question of the answer may be yes and may be no.

Its really simple to miss there are already hidden abtractions layer in the native opengl driver. So the major difference between native driver and zink is visibility of abstraction layers.

[smitty3268]

I would not say this is true either. There is a problem. You have missed. Opengl as a standard is basically end of life. So new Opengl extensions will stop coming.

Here is where things get really fun. No new Opengl extension but lets say Vulkan gets released with a new feature that could help your application massively how are you going to access it without recoding your complete application or even rebuilding the binary.

There is absolutely no reason the same hardware access couldn't be built directly into an OpenGL driver, and then automatically used by the driver even if it's never exposed through an API to the application directly. (Or it could be exposed through a new vendor extension)

It is fair to argue that vendors may not go to the trouble of updating their GL drivers anymore now that the API is largely done, but it's clearly possible for them to do so if they are motivated.

Over time, I suspect GL over Vulkan may take the place of a direct OpenGL driver, but that will be many years in the future when the performance of GL apps is no longer particularly important to most people. Similar to the way DX9 works now.

[oiaohm]

There is absolutely no reason the same hardware access couldn't be built directly into an OpenGL driver, and then automatically used by the driver even if it's never exposed through an API to the application directly. (Or it could be exposed through a new vendor extension)

Except your GPU with modern applications has to accept Vulkan on Linux or Dx12 on windows. So you need opengl support to play ball with these other systems.

Also Khronos behind opengl is also starting to restrict what new extensions that can be created for Opengl. End of life is coming for Opengl is now in maintenance mode.

Remember creating new opengl vendor extensions don't help with legacy applications that will not know how to use it. This is where the vulkan layer system is so different to prior opengl.

Vulkan layer system is a very critical feature not to over look same with the fact that opengl is end of life right now.

but it's clearly possible for them to do so if they are motivated.

The point is a vendor even motivated can only go so far against Khronos group going too far sees vendor out of the patent pool they need operate. Collective vendor will is at play here.

[smitty3268]

Except your GPU with modern applications has to accept Vulkan on Linux or Dx12 on windows. So you need opengl support to play ball with these other systems.

That has nothing to do with anything being discussed here.

Also Khronos behind opengl is also starting to restrict what new extensions that can be created for Opengl. End of life is coming for Opengl is now in maintenance mode.

There's no way Khronos is going to block NVidia or AMD from creating new vendor extensions anytime soon. I doubt they'd do that 10 years from now.

Remember creating new opengl vendor extensions don't help with legacy applications that will not know how to use it.

The same is true for any GL application running on a vulkan backend....

This is where the vulkan layer system is so different to prior opengl.

Not sure what that has to do with anything. It provides some nice flexibility going forward, sure, but I don't see how it helps run legacy GL apps any faster. And if it did, an OpenGL driver could embed something similar into itself. That's clearly a possibility, because... The GL driver built on Vulkan can do it. Ok, sure - it'd require a massive rewrite that will never happen, but then again it's very unclear what the benefit is for just implementing a legacy API too.

Vulkan layer system is a very critical feature not to over look same with the fact that opengl is end of life right now.

Disagree with the first, precisely because of the 2nd.

The point is a vendor even motivated can only go so far against Khronos group going too far sees vendor out of the patent pool they need operate. Collective vendor will is at play here.

If your only point is that vendors will refuse to maintain their OpenGL drivers, then ok. Like I said, that's certainly a valid point of view. I just don't see that happening on the desktop side for a few more years, at least. On the mobile/embedded side, it's likely already happening. Regardless, that's just a matter of the vendors choosing to work on their drivers or not, so it's not a technical problem but a business issue with money. Running a GL layer on top of Vulkan could potentially run into actual technical hurdles it would need to resolve.

[oiaohm]

There's no way Khronos is going to block NVidia or AMD from creating new vendor extensions anytime soon. I doubt they'd do that 10 years from now.

Core structure of opengl changes are kind of dead. NVidia/AMD doing stuff on own will not get very far at this point. Putting Opengl on Vulkan gives you a big structural change without needing major agreements.

Not sure what that has to do with anything. It provides some nice flexibility going forward, sure, but I don't see how it helps run legacy GL apps any faster.

Some of it is that the legacy GL application can function at all. Vulkan layers allows implementing application quirk support without needing the opengl vendor to-do it. This could be the quirk like for dxvk needing all allocated memory zeroed( this was fixed by a Vulkan layer). Old applications can be expecting undefined by specifications graphics card behaviours that new cards should not do.

And if it did, an OpenGL driver could embed something similar into itself. That's clearly a possibility, because... The GL driver built on Vulkan can do it. Ok, sure - it'd require a massive rewrite that will never happen, but then again it's very unclear what the benefit is for just implementing a legacy API too.

Its not that straight forwards. Vulkan was designed from the ground up to have layers and Vulkan design mandates they must be there. Opengl has not mandated the layer form man in the middle. So yes massive rewrite to drivers to bring layer like functionality to existing opengl drivers even mesa ones and is this really worth it if opengl on vulkan grants the same thing.

https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Validation_layers

Yes when you on on vulkan your program can basically be running without any validation unless you decide to turn the validation layers on.

So vulkan everything is configured that you may place a layer in at between application and hardware without altering the application or the drivers. This can be a layer that makes application calling a old vulkan function use a new vulkan function instead or use some other setting on that function call or possible behave that it does not have a feature when it does and so on. All these changes can be done by the application writer or third party creating a vulkan layer without needing the graphics driver makers to do them.

Remember all the vulkan quirk handling done in layers like for dxvk and other things is usable by opengl on vulkan.

The fun of the problem of quirks. Opengl on Vulkan could make the amount of code need to handle the hardware quirk emulation less because the vulkan layers to make application see hardware that does not have X quirk to have X quirk so it does not crash will be generic vulkan layer usable by everything.

Vulkan layers is kind of a big thing. Its not always performance Vulkan layers could allow more applications to work. The overhead of opengl on vulkan may not be great we will not know until zink is more complete.

Running a GL layer on top of Vulkan could potentially run into actual technical hurdles it would need to resolve.

Vulkan layer system make a lot of technical issues simple to resolve using Vulkan documented methods that under opengl you are using vendor unique/undocumented methods with normally more limitations on what you can do. In the case of issues that Vulkan it self current cannot handle some GL layer needs there are always new Vulkan extensions as option to fix the problems.

Vulkan layer system is a good thing. Problem is making opengl native driver implementation have the same as Vulkan layer system for emulating hardware defects and so on you basically at core a re-implementing Vulkan. Of course with this being the case the question comes how big if any cost is there putting opengl on vulkan that zink may nicely answer.

Vulkan layer system comes out of all the issues learnt from attempting to do the Opengl Compatiblity profile.