Zink OpenGL-Over-Vulkan With Unigine Heaven Seeing Improved Performance

[chocolate]

It would be cool if Zink was able to run Tomb Raider's Mountain Village faster than OpenGL in the future, though I am not sure whether the bottleneck is just in Mesa or also in the Tomb Raider binary itself.

They haven't updated the game on PC when improved assets were made for PS4/XO, so I don't think they will now. And Feral will probably never acquire new source material for TR13, or be paid again to hack the engine for Linux.

Crystal Dynamics just doesn't care. A clown representative (the "game director" himself, I think) once appeared on video shaking a Microsoft guy's hand to say they were partnering to bring us the best RotTR possible, then proceeded to recycle so many assets from TR13 that it's not even funny. And I'm not just talking about small objects, oh no, they lifted *entire sections* from TR13 and put some different textures here and there. If it's not immediately obvious from the very start of the game (animations and geometry), don't worry, it becomes apparent later on.
What a shame. The core gameplay mechanics are fun, the rest sucks.

[AsuMagic]

Can someone explain to me why this needs to exist? OpenGL over Vulkan will always be slower than OpenGL directly, right? Not to mention just Vulkan is even faster. This almost feels like an excuse no to switch from OpenGL to Vulkan. Am I missing something here?

(disclaimer: i don't know shit about drivers or vulkan)

To be more precise: OpenGL over Vulkan will always have less performance *potential* than a native implementation.
If you are competing against a slow native OpenGL implementation, odds are that you may get comparable or better performance with a very good OpenGL over Vulkan implementation.
One native OpenGL implementation that does not get much love would be AMD's Windows OpenGL implementation, for instance. I imagine it would be significantly harder to compete with e.g. radeonsi or NVIDIA's OpenGL.

For example, DXVK usually doesn't reach full native performance of AMD's/NVIDIA's native D3D11 implementation, but in specific cases it can. I think there were a few instances where DXVK outperformed the native driver, IIRC for instance RADV+ACO+DXVK in NieR:Automata, and yet AMD's D3D11 implementation does not suck.

Also, such a compatibility layer means that where you have a Vulkan implementation, you have OpenGL. I haven't really looked into Zink's portability plans but I could imagine that it could eventually be used to have OpenGL over Vulkan over Metal (MoltenVK) for the day where Apple may abandon native OpenGL drivers (as MoltenGL, IIRC, is paid, as opposed to MoltenVK which is FOSS, thanks to Valve IIRC?).

Legacy software (games, especially) is not going away. Porting these is impossible when closed source and difficult at best otherwise. Plus, going full Vulkan is not always a great idea if you're developing a game - my 2009 laptop does not support Vulkan and I can still run Minecraft, Besiege, and a few 2D games just fine. Middleware like bgfx can be nice in those cases rather than writing against Vulkan/OpenGL directly though.

[Dr. Righteous]

Can someone explain to me why this needs to exist? OpenGL over Vulkan will always be slower than OpenGL directly, right? Not to mention just Vulkan is even faster. This almost feels like an excuse no to switch from OpenGL to Vulkan. Am I missing something here?

For all the benefits of Vulkan (a win-win for everyone) the mass migration away from legacy APIs like OpenGL and DirectX never happened.
I think 2 things are at play. One is Microsoft dominance over software development and another people (developers) are just lazy.
This is how we do it, this is how we've always done it, this is how we are doing it.

[R41N3R]

Did somebody test this already? I tried to build it but somehow I had no luck with the instructions.

I'm very excited about getting Zink merged back upstream. Radeonsi works great here but I really want to use something Vulkan based at least for testing :-)

[brad0]

For all the benefits of Vulkan (a win-win for everyone) the mass migration away from legacy APIs like OpenGL and DirectX never happened.

DirectX is not legacy API. Literally no one is going to migrate from the native well supported API to API that doesn't have the same level of support and testing from the OS vendor. The very few times you see Vulkan use on Windows is from companies who never bothered to write a DirectX renderer in the first place. The same goes for macOS and Metal.

[nanonyme]

To be more precise: OpenGL over Vulkan will always have less performance *potential* than a native implementation.
If you are competing against a slow native OpenGL implementation, odds are that you may get comparable or better performance with a very good OpenGL over Vulkan implementation.
One native OpenGL implementation that does not get much love would be AMD's Windows OpenGL implementation, for instance. I imagine it would be significantly harder to compete with e.g. radeonsi or NVIDIA's OpenGL.

There's also the thing that it's apparently harder to do a good OpenGL implementation than a good Vulkan implementation so if having good OpenGL over Vulkan implementation could be made to beat mediocre OpenGL implementation, it may stop being so interesting to write *new* OpenGL drivers. The old ones have had a long time to mature and be optimized so they will probably remain the default forever.

[Ladis]

If you are competing against a slow native OpenGL implementation, odds are that you may get comparable or better performance with a very good OpenGL over Vulkan implementation.

(...)

I could imagine that it could eventually be used to have OpenGL over Vulkan over Metal (MoltenVK) for the day where Apple may abandon native OpenGL drivers (as MoltenGL, IIRC, is paid, as opposed to MoltenVK which is FOSS, thanks to Valve IIRC?).

Yes, macOS is an example where the wrapper (MoltenGL) is faster (and has more features) than the native/direct OpenGL (which is going to be removed anyway). I'm also looking forward to the free solution to run OpenGL on macOS after they remove the native one (OpenGL-->Vulkan-->Metal via MoltenVK for free and MoltenGL for paying customers requiring the technical support).

[cl333r]

I always assumed that sooner or later it would happen, it was just a matter of the zink code mature enough, and then the developers would have all the freedom to push and optimize according to their intuitions and their creativity. And I think this is just the beginning, I can't wait for the engineers to start getting more familiar with vulkan code and push the design of hardware that enters into symbiosis with vulkan to push the limits even further ... this level of freedom is not conditioned by market strategies, and could appear overnight, at any time.

I'm not sure you read the article, it implies that Zink is still slower than the original OpenGL path - which is not news at all and not exciting either.

[Ladis]

I'm not sure you read the article, it implies that Zink is still slower than the original OpenGL path - which is not news at all and not exciting either.

Step one, features, step two, performance. They just started the step 2.

[R41N3R]

From 14 to 24 FPS in the Unigine bechmark is impressive for this short optimization phase :-)
https://www.supergoodcode.com/accelerate/ and https://www.supergoodcode.com/engage-thrusters/

With almost 50% of the OpenGL performance this looks really promising!