Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by coder View Post
    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.

    Leave a comment:


  • coder
    replied
    Originally posted by oiaohm View Post
    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!

    Leave a comment:


  • oiaohm
    replied
    Originally posted by coder View Post
    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.

    Originally posted by coder View Post
    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.

    Leave a comment:


  • coder
    replied
    Originally posted by oiaohm View Post
    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.

    Leave a comment:


  • pracedru
    replied
    Originally posted by oleid View Post

    Only if vulkan drivers will have uniform behaviour accross hardware.
    I did write maybe. But not necessarily actually. There could be differences in Vulkan implementations that aren't affecting the Zink stuff.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by coder View Post
    Don't underestimate corner cases. Even if there are just a few corner cases where Zink really falls down, that's enough to make it unusable for some people.
    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.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by dragon321 View Post

    Yeah. While it seems Zink was not meant to replace existing native OpenGL implementations, it can serve this purpose in near future as well.
    I wont be surprised if we see raspberry pi's head this way when v3dv hits 1.1 conformance

    Leave a comment:


  • dragon321
    replied
    Originally posted by wertigon View Post

    90% of Native drivers is actually good enough for most tasks. This is really promising, perhaps in a year or so we will see Zink be the default OpenGL solution in distros like Fedora.
    Yeah. While it seems Zink was not meant to replace existing native OpenGL implementations, it can serve this purpose in near future as well.

    Leave a comment:


  • coder
    replied
    Originally posted by wertigon View Post
    90% of Native drivers is actually good enough for most tasks. This is really promising, perhaps in a year or so we will see Zink be the default OpenGL solution in distros like Fedora.
    Don't underestimate corner cases. Even if there are just a few corner cases where Zink really falls down, that's enough to make it unusable for some people.

    Leave a comment:


  • sandy8925
    replied
    Great! Hopefully I can replace the RadeonSI OpenGL driver with this.

    It's been super buggy under Mesa 21.1, causing GPU and system crashes, several times a day. Makes the system unusable.

    Leave a comment:

Working...
X