Zink OpenGL-On-Vulkan Now "100%-1000% Faster" For Many Scenarios

[coder]

The corner cases cut both ways. There are corner cases for old applications where current vendor opengl drivers don't work right as well. This explains the value support.

Huh? Are you speaking from direct knowledge, or just assumptions?

I know a lot of work has gone into AMD Pro and the open-source drivers to be bug-compatible with Nvidia drivers, specifically for the sake of older applications.

And what I was originally referring to wasn't even about functional correctness or bug-compatibility, but actually performance. If there are some corner cases where the performance of Zink falls off a cliff, that could be a deal-breaker for apps that hit those cases, even if its behavior is what they expect.

[oiaohm]

I know a lot of work has gone into AMD Pro and the open-source drivers to be bug-compatible with Nvidia drivers, specifically for the sake of older applications.

There is horrible here that some older games that gogo and valve have were in fact made for ATI bugs that are not in fact Nvidia bug compatible. AMD Pro has put in a lot of work for programs in the last 12 years. Valve and gogo will at times be attempting to sell games that are binary for windows from 1995 to current day. Of course you have the dos games that get run in dosbox but that not going to be using opengl directly and expecting stuff to act odd.

And what I was originally referring to wasn't even about functional correctness or bug-compatibility, but actually performance. If there are some corner cases where the performance of Zink falls off a cliff, that could be a deal-breaker for apps that hit those cases, even if its behavior is what they expect.

This brings you to one of the wacky. Some of the places where Zink performance falls off cliffs results in some of those really old games behaving themselves as well. There are games that depend on particular opengl operations being slow when they are not the game does not work right.

I can see in future that Zink will kind of split in 3.
1) 1995 to about 2005 ATI only quirks and early opengl optimised games. Just up until ATI got aquired by AMD they were working with some game companies resulting in some game in their engines having oddities.
2) 1999- current being Nvidia quirk compatible stuff.
3) The I follow specification implementation.

Yes I know there is a date overlap between 1 and 2 but there were games from 1999-2005 that the game engine is ATI and old opengl implementationparticular and has issues on Nvidia cards even into the current day.

Please note the 1994-2005 opengl expected behaviours by particular games are normally doing things that are not even close to the formal specification at the time.

Thing to remember valve and gogo and few other game distributions have games they could legally sell but they do not sell because their game engine/binary depends on some vendor GPU quirk that current hardware does not support. Of course being binary that don't have the source code to fix it either.

As I said this issue explains why Valve is so willing to fund development in this area. Also explains why having the best performance may not always be on the fund developers mind making Zink as there will be games in the Valve collection that they are not current selling because the game is unplayablewhen using a particular feature that is too fast. So this is a double side coner case problem. So bad performance when using X feature breaks one user but a user wanting to play X game that need that to perform bad so the engine works right will be like great problem fix.

Yes

https://xkcd.com/1172/

The xkcd workflow comic really fits here. What is bad workflow for one group of users is good workflow for another when it comes to these Zink bugs.

[coder]

This brings you to one of the wacky. Some of the places where Zink performance falls off cliffs results in some of those really old games behaving themselves as well. There are games that depend on particular opengl operations being slow when they are not the game does not work right.

I think there are better solutions for slowing down old games, for the folks who need to do that. Your idea that some unoptimized corner cases in Zink could happen to match what these old games need/expect and slow them down just the right amount seems improbable and definitely like "spacebar heating", in the rare case where it would happen to work out!

[oiaohm]

I think there are better solutions for slowing down old games, for the folks who need to do that. Your idea that some unoptimized corner cases in Zink could happen to match what these old games need/expect and slow them down just the right amount seems improbable and definitely like "spacebar heating", in the rare case where it would happen to work out!

Lot of the optimised happens to have locking features that match the older hardware. So its not exactly as rare as one expects that a unoptimsied opengl driver happens to make old applications work that will not work on modern opengl drivers.

Some of this is like of items you could out of order execute vs doing them all in order. Early opengl hardware lot of cases did not have the means to do as much in parallel or do as much out of order.

Remember lot of Zink optimisation is to go from areas running single thread to running multi thread. Just happens the way you performmance boost opengl for modern day applications is way you alter things to be incompatible with some of the early opengl stuff. Of course is expecting undefined by specification opengl behaviour in both cases.

Yes wanting bad performance seams wrong but when the old applications are expecting particular opengl functions basically to be processed 1 at time can be doing stupid things like writing to a buffer with cpu while a stack of instructions opengl instructions that are modern day could go out of order and be faster are going to access that bad things will happen because the old program was thinking that would be slow and would have had time to write that buffer before the GPU wanted the buffer.

There is really need for a split somewhere between the old legacy opengl applications and the modern day ones.

I know the following is kind of horrible to know is from 1998-2008 with DRI1 this only really support 1 application of opengl using X11 server at the time. Its really not that far back do when you start hitting applications expecting opengl behaviour that modern day systems will not have.

--Another drawback was that operations didn't retain memory allocations after the current DRI process released its lock on the device, so any data uploaded to the graphics memory such as textures were lost for upcoming operations, causing a significant impact on graphics performance.--
I know above is from the wikipedia about dri1 but its true. The split should have been from 1995-2008 with the end of dri1. Yes you disconnect from the DRI1 device reconnect and you could expect that the memory in the GPU was flushed. Modern day applications are not going to expect the behaviour. There is lack of need to consider sharing as well since only 1 application has access to the GPU and lack of threading optimisations in early opengl.

The reality is quite a few unoptimized corner cases of zink do exactly match the early opengl behavour. Yes this is really because the hardware back then was not multi core cpu and the gpu was not multi thread/application being shared so there was excess locking and lack of threading in the early opengl stuff.