Announcement

Collapse
No announcement yet.

Enabling HyperZ Is Still An Easy Way For Faster RadeonSI Performance

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

  • #21
    Originally posted by 0xBADCODE View Post
    From what I know, proprietary drivers are using similar techniques. I even read somewhere some GPU drivers gone as far as daring to replace shaders of some most popular titles with their own optimized implementations.
    Yes, and it's repeatedly been stated all over the internet how much of a clusterfuck they are because of that. Separate codepaths for thousands of applications is how you get the 100MB driver size, where generic functionality only works if the executable is named in a certain way, benchmarks get cheated, app graphical quality suffers, and in the best cases, the shader they replace has been updated to do something else in the later game versions, and the replacement thus breaks everything.

    It would be a huge amount of work to gather that test data, and nobody would be happy to have a 100MB data file in their home dir.

    Comment


    • #22
      Originally posted by curaga View Post
      Yes, and it's repeatedly been stated all over the internet how much of a clusterfuck they are because of that. Separate codepaths for thousands of applications is how you get the 100MB driver size, where generic functionality only works if the executable is named in a certain way, benchmarks get cheated, app graphical quality suffers, and in the best cases, the shader they replace has been updated to do something else in the later game versions, and the replacement thus breaks everything.

      It would be a huge amount of work to gather that test data, and nobody would be happy to have a 100MB data file in their home dir.
      I would agree it is clusterfuck when it comes to all this cheating with shaders. Actually looks like people all around got really fed up with all this crap to degree where OpenGL Next (and competitors) are in heavy demand, as far as I understand it supposed to be low level enough to make such dirty hacks not needed in many cases. Yet, as you can see, various GPUs seems to have specifics and/or not each and every code path works great with each and every program. So it is a question if neat looking/less hacky code outweighs worse performance and longer feature integration times.

      For me it looks like this: if it happens that hyper-z works fine in 99% cases but 1% of cases prove itself to be exceptionally hard to nail down in a reasonable timeframe, it can make sense to blacklist few programs and allow others to get improved performance. This is not hyper-z specific but rather approach which can be used on different features. And MESA already haves simplified version of this. I would agree that whole need to do app-level workarounds indicates bug or even something worse. However, we live in real world and from what I can see, in real world with real code and real bugs it happens this way, regardless if you like it or not. Because it can give better performance without stability loss.
      Last edited by 0xBADCODE; 31 August 2014, 02:29 AM.

      Comment


      • #23
        You can control hyper-Z on a per-app basis right now

        Originally posted by 0xBADCODE View Post
        I would agree it is clusterfuck when it comes to all this cheating with shaders. Actually looks like people all around got really fed up with all this crap to degree where OpenGL Next (and competitors) are in heavy demand, as far as I understand it supposed to be low level enough to make such dirty hacks not needed in many cases. Yet, as you can see, various GPUs seems to have specifics and/or not each and every code path works great with each and every program. So it is a question if neat looking/less hacky code outweighs worse performance and longer feature integration times.

        For me it looks like this: if it happens that hyper-z works fine in 99% cases but 1% of cases prove itself to be exceptionally hard to nail down in a reasonable timeframe, it can make sense to blacklist few programs and allow others to get improved performance. This is not hyper-z specific but rather approach which can be used on different features. And MESA already haves simplified version of this. I would agree that whole need to do app-level workarounds indicates bug or even something worse. However, we live in real world and from what I can see, in real world with real code and real bugs it happens this way, regardless if you like it or not. Because it can give better performance without stability loss.
        I forget the exact code to do so, but games can be called from terminal or script with hyper-Z enabled or disabled when the default is to the contrary, If it works on most of your applications and games, I would suggest enabling hyper-Z and having your launchers (.desktop files) for any offending games invoke a script that calls them with hyper-Z turned off.

        Comment


        • #24
          Originally posted by Luke View Post
          I forget the exact code to do so, but games can be called from terminal or script with hyper-Z enabled or disabled when the default is to the contrary, If it works on most of your applications and games, I would suggest enabling hyper-Z and having your launchers (.desktop files) for any offending games invoke a script that calls them with hyper-Z turned off.
          It is R600_DEBUG=hyperz environment variable. However, this method is not anyhow user-friendly. For good user experience things should work reasonably by default. Not after you've spent some time to fix them. It's not like if I'm happy to hear MESA is slow/buggy/for nerds only/whatever crap people can muble as a result of such approaches.

          Comment

          Working...
          X