Announcement

Collapse
No announcement yet.

Valve's ACO AMD Shader Compiler Now Can Handle Vertex Shaders

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

  • Valve's ACO AMD Shader Compiler Now Can Handle Vertex Shaders

    Phoronix: Valve's ACO AMD Shader Compiler Now Can Handle Vertex Shaders

    Valve's interesting ACO shader compiler alternative to AMDGPU LLVM currently for the RADV Vulkan driver as well as for RadeonSI OpenGL in the future now can handle vertex shaders...

    http://www.phoronix.com/scan.php?pag...er-Vertex-Shad

  • #2
    Cool, gonna give this a shot later today. I haven't tried it yet so I'm curious if it'll improve any games I'm playing.

    A quick scan of the issues shows that it doesn't seem to like in-game MSAA settings, but I didn't see anyone reporting using the MSAA/EQAA environment variable so I wonder if that's a workaround or if it'll work better.

    If y'all don't know, these are all the supported values we can use with AMDGPU+MESA based on an AMD MSAA tech sheet. I have 4f8x enabled globally in /etc/environment so all my games use it.

    Edit: Should add that I posted without thinking and that these only work with RadeonSI, not RADV.
    # No MSAA
    EQAA=0,0,0
    # 4x MSAA
    EQAA=4,4,4
    # 4f16x EQAA
    EQAA=16,4,4
    # 2x MSAA
    EQAA=2,2,2
    # 2f8x EQAA
    EQAA=8,2,2
    # 8x MSAA
    EQAA=8,8,8
    # 2f4x EQAA
    EQAA=4,2,2
    # 4f8x EQAA
    EQAA=8,4,4
    # 8f16x EQAA
    EQAA=16,8,8
    Last edited by skeevy420; 07-30-2019, 07:50 AM.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      ...
      First of all, those env vars don't force MSAA if a game doesn't actually use it, it just uses a different MSAA implementation if the rendering is multisampled anyways.
      Enforceable MSAA was removed form Mesa ages ago, because it just doesn't work with certain renderer designs: https://lists.freedesktop.org/archiv...er/067864.html
      Also, they are radeonsi specific, and since ACO is only relevant for RADV at the moment, they won't do anything.

      Comment


      • #4
        Michael, well, please do a performance comparison in games with Mesa+LLVM vs Mesa+ACO vs Windows 10!

        Comment


        • #5
          Originally posted by skeevy420 View Post
          A quick scan of the issues shows that it doesn't seem to like in-game MSAA settings
          I don't see any issue with MSAA in SS: Fusion.

          Comment


          • #6
            Valve putting so much attention into AMD graphics, despite the low market share and mining business probably means Steam Machine 2.0 with AMD graphics is coming. Doing this just as a favor for 15 people would be quite illogical.

            Comment


            • #7
              Originally posted by aufkrawall View Post
              I don't see any issue with MSAA in SS: Fusion.
              Reading through the open and closed issues, in-game MSAA with black squares seems to be a common issue. Though it also seems to be related to DXVK+MSAA which could be why a native game might work just fine.

              Comment


              • #8
                Originally posted by Masush5 View Post
                First of all, those env vars don't force MSAA if a game doesn't actually use it, it just uses a different MSAA implementation if the rendering is multisampled anyways.
                Enforceable MSAA was removed form Mesa ages ago, because it just doesn't work with certain renderer designs: https://lists.freedesktop.org/archiv...er/067864.html
                Also, they are radeonsi specific, and since ACO is only relevant for RADV at the moment, they won't do anything.
                We're both wrong. What I'm referring to is completely different than enforceable MSAA and it was introduced last year with Mesa 18.2; four years after that was removed.

                The AMD specific EQAA variable only works with radeonsi...so yeah, probably won't matter here until ACO focuses on radeonsi whenever RADV is done.

                We all make dumb mistakes early in the day

                Comment


                • #9
                  Originally posted by eydee View Post
                  Valve putting so much attention into AMD graphics, despite the low market share and mining business probably means Steam Machine 2.0 with AMD graphics is coming. Doing this just as a favor for 15 people would be quite illogical.
                  To be fair, doing a whole console for 15 people is even more illogical, don't you think?

                  Comment


                  • #10
                    Originally posted by eydee View Post
                    Valve putting so much attention into AMD graphics, despite the low market share and mining business probably means Steam Machine 2.0 with AMD graphics is coming. Doing this just as a favor for 15 people would be quite illogical.
                    AMD is putting so much effort into graphics because they're used and officially supported on the PS4 & Pro; Xbox One & Elite; PS5; Xbox Two; Google Stadia; Windows 7-10; Ubuntu, Cent, Suse, & Fedora; and more.

                    Let's put in all this effort to get supported on all of that and say "screw it, let's drop the ball" is quite illogical.

                    Comment

                    Working...
                    X