Announcement

Collapse
No announcement yet.

AMD R600 Gallium3D Optimizing Back-End Merged

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

  • AMD R600 Gallium3D Optimizing Back-End Merged

    Phoronix: AMD R600 Gallium3D Optimizing Back-End Merged

    Vadim Girlin's shader-optimizing back-end for the AMD R600 Gallium3D driver has been merged into mainline Mesa...

    http://www.phoronix.com/vr.php?view=MTM2MjA

  • #2
    r600g/sb: initial commit of the optimizing shader backend -0/+17498
    I don't know how much of that is autogenerated, but it sure looks like a bigger chunk of work, so of course a big thanks who make stuff like this possible.

    Will this be usable for radeonsi in the future too?

    edit: Even with documentation!
    http://cgit.freedesktop.org/mesa/mes...notes.markdown
    Last edited by ChrisXY; 04-30-2013, 04:45 PM.

    Comment


    • #3
      Originally posted by phoronix View Post
      Phoronix: AMD R600 Gallium3D Optimizing Back-End Merged

      Vadim Girlin's shader-optimizing back-end for the AMD R600 Gallium3D driver has been merged into mainline Mesa...

      http://www.phoronix.com/vr.php?view=MTM2MjA
      This is the patchset which brings Unigine Heaven to Windows 7 performance.

      Things just keep getting better and better!

      And to think that OpenCL is making progress and that the PM code has already been written and is awaiting release.... W00t w00t!

      Comment


      • #4
        Looks like I may have to start considering using the FOSS drivers.

        Comment


        • #5
          Originally posted by pingufunkybeat View Post
          This is the patchset which brings Unigine Heaven to Windows 7 performance.

          Things just keep getting better and better!

          And to think that OpenCL is making progress and that the PM code has already been written and is awaiting release.... W00t w00t!

          just took Shank2 for a test-run and it's really noticably more fluid (e.g. the llvm-backend gained some small noticable improvement but with Vadim Girlin's tweaks performance really seems to shine

          would be interesting to see in the long-run how stability is with R600_DEBUG=sb

          w00t w00t !

          Comment


          • #6
            Originally posted by ChrisXY View Post
            r600g/sb: initial commit of the optimizing shader backend -0/+17498
            I don't know how much of that is autogenerated, but it sure looks like a bigger chunk of work, so of course a big thanks who make stuff like this possible.

            Will this be usable for radeonsi in the future too?

            edit: Even with documentation!
            http://cgit.freedesktop.org/mesa/mes...notes.markdown

            Unlykly.

            AMD devs want to utilise LLVM for all the low level stuff in their drivers, while this code is custom made. That is also why AMD devs have trouble with accepting this code. That would mean supporting unfamiliar code, while they want to focus on LLVM.

            And since its just r600g it wont work for radeonSI, and even if its highly succesfull for r600g gen hardware, radeonSI support different hw, so what works for r600g-sb may not work for newer GPU's.

            Comment


            • #7
              Originally posted by przemoli View Post
              Unlykly.

              AMD devs want to utilise LLVM for all the low level stuff in their drivers, while this code is custom made. That is also why AMD devs have trouble with accepting this code. That would mean supporting unfamiliar code, while they want to focus on LLVM.

              And since its just r600g it wont work for radeonSI, and even if its highly succesfull for r600g gen hardware, radeonSI support different hw, so what works for r600g-sb may not work for newer GPU's.
              They have said before that this code is just a stop-gap measure. They know its not the longterm solution. But the longterm (LLVM) solution is better than the current solution, BUT this solution is better than the longterm one right now. Its being merged knowing full well that it will be bin'ed once LLVM is optimized and under better handling.

              Comment


              • #8
                Originally posted by przemoli View Post
                AMD devs want to utilise LLVM for all the low level stuff in their drivers, while this code is custom made.
                I thought that this work ran very late, on HW instructions, so it can be run with LLVM too.

                Of course that the optimisations themselves will eventually be done by LLVM as its backend improves. In the meantime, this can run after LLVM generates HW instructions, it doesn't hurt anything there.

                Comment


                • #9
                  Originally posted by pingufunkybeat View Post
                  I thought that this work ran very late, on HW instructions, so it can be run with LLVM too.

                  Of course that the optimisations themselves will eventually be done by LLVM as its backend improves. In the meantime, this can run after LLVM generates HW instructions, it doesn't hurt anything there.
                  IIRC, there were cases where LLVM+r600-sb, made bad result against r600-sb alone.

                  Comment


                  • #10
                    Originally posted by Drago View Post
                    IIRC, there were cases where LLVM+r600-sb, made bad result against r600-sb alone.
                    That's true, but i think at least 1 of those problems has already been addressed. I'm not sure if they all have or not, or whether it's mostly helpful with only a few regressions or if it has lots of problems.

                    Sounds like a good thing for Michael to test.

                    / i'm going to cry when michael's tests only consist of the quake 3 engine.

                    Comment

                    Working...
                    X