Announcement

Collapse
No announcement yet.

RADV ACO Lands NGG Geometry Shader Support

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

  • #11
    Originally posted by mcoffin View Post
    I honestly had no idea that this wasn't already supported since it's been supported by AMDVLK for so long. I primarily use mesa with the exception of one or two edge-case games, since it generally offers better performance, but this is nice to see! I wonder if mesa will expose primitive ordered shaders or not, as AMDVLK chose not to.
    Because geometry shaders are not commonly used and the NGG path isn't needed or really faster on current hardware. So why implement something that's optional and a decent amount of work?

    Comment


    • #12
      Originally posted by mcoffin View Post
      I honestly had no idea that this wasn't already supported since it's been supported by AMDVLK for so long. I primarily use mesa with the exception of one or two edge-case games, since it generally offers better performance, but this is nice to see! I wonder if mesa will expose primitive ordered shaders or not, as AMDVLK chose not to.
      The RADV/LLVM backend has supported NGG GS for a long time, but we didn't really get a noticable performance improvement from it. This was also the case when we added NGG VS/TES to ACO a few months ago. This is why NGG GS wasn't a priority for us. Also, few apps use GS at all, so it's not the most important area, in my opinion.

      Personally, I think that NGG is a very good way to unify the geometry pipeline (excluding tessellation) into a single HW stage, you can think of it as a merged ES+GS+VS hardware stage. But it seems that it's not a silver bullet that will magically speed things up.

      On the other hand, NGG is absolutely necessary to implement stuff like mesh shaders for example.

      Comment


      • #13
        Originally posted by skeevy420 View Post

        Maybe, but my monitor can't even go into standby on Windows without crap going wrong. Monitor goes on standby, I wake it up, and the monitor blanks on and off every two seconds until I power cycle my monitor. I think it's because I'm using HDMI and HDCP goes wonky around the time my monitor goes into standby or wakes up. All I know is that it doesn't happen on Linux at all.

        It gets old dealing with the same bug every time you leave your system for 5 minutes.
        Windows refuses to suspend for me. It just wakes itself up after a few seconds. Or never goes into suspend. If I use Windows I have to shut it down once I'm done.
        ​​​​​​

        Comment


        • #14
          Originally posted by Venemo View Post

          The RADV/LLVM backend has supported NGG GS for a long time, but we didn't really get a noticable performance improvement from it. This was also the case when we added NGG VS/TES to ACO a few months ago. This is why NGG GS wasn't a priority for us. Also, few apps use GS at all, so it's not the most important area, in my opinion.

          Personally, I think that NGG is a very good way to unify the geometry pipeline (excluding tessellation) into a single HW stage, you can think of it as a merged ES+GS+VS hardware stage. But it seems that it's not a silver bullet that will magically speed things up.

          On the other hand, NGG is absolutely necessary to implement stuff like mesh shaders for example.
          Very valuable post. Thanks for it!

          Comment

          Working...
          X