Announcement

Collapse
No announcement yet.

Running The RadeonSI NIR Back-End With Mesa 19.1 Git

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

  • #11
    Originally posted by AsuMagic View Post
    I feel sorry for the Windows AMD OpenGL driver. Getting destroyed so hard must hurt
    Maybe at some time AMD can switch their windows driver to Mesa? Either by using Zink (Gallium over Vulkan) or by making an AMDGPU windows driver. After all, code sharing was an argument for DC/HAL anyway.

    Comment


    • #12
      Originally posted by Marc Driftmeyer View Post

      And yet no one cares in the Windows world as games use DirectX and not OpenGL.
      Well No Mans Sky somehow runs decent under windows and OpenGL, so I dunno.

      Comment


      • #13
        Originally posted by tarceri View Post
        I'm pretty happy with these results. There are still a number of known optimisations missing for the NIR backend vs the TGSI backend.
        Note:
        It was tested with Vega, here.
        I see one little triangle corruption under UH with Polaris 20 (RX580). - Marek know that.
        The above corruption is FIXED with current Mesa git + Marek's latest SDMA patches.
        BUT sadly reliable _whole_ system hang under UH and UV with my Polaris 20 (Nitro+) => VM faults (I've to dig.)

        Kernel:
        latest 'amd-staging-drm-next' 0bf64b0a9f7850809c4da2fafce36d1504cc28d9

        Mesa git:
        49397a3c840b38f8c65705dd05d642c0beb4dea9 plus

        c459985765e (HEAD -> master) radeonsi: use SDMA for uploading data through const_uploader
        0039866bee8 gallium/u_upload_mgr: allow use of FLUSH_EXPLICIT with persistent mappings
        bb3dfd0b68c gallium/u_threaded: always unmap const_uploader
        78a5adca84d st/mesa: always unmap the uploader in st_atom_array.c
        0a5446396fc winsys/amdgpu: cs_check_space sets the minimum IB size for future IBs
        c60e63f5eb1 winsys/amdgpu: clean up IB buffer size computation
        f63402c437f winsys/amdgpu: remove occurence of INDIRECT_BUFFER_CONST
        a7540f5aa48 winsys/amdgpu: use a separate fence list for syncobjs
        f5340535a1c winsys/amdgpu: unify fence list code
        6c93ed58404 winsys/amdgpu: don't drop manually added fence dependencies
        0146f9a0e00 radeonsi: fix EXPLICIT_FLUSH for flush offsets > 0
        59f6cec379b gallium/u_threaded: fix EXPLICIT_FLUSH for flush offsets > 0
        22335474274 radeonsi: re-initialize query buffers if they are reused

        Comment


        • #14
          Congratulations to the devs, it's not finished and yet already faster!
          It'd be awesome if the min could also be higher than with TGSI of course.

          Is the support of OGL 4.5 complete with NIR already?

          Comment


          • #15
            Originally posted by theriddick View Post

            Well No Mans Sky somehow runs decent under windows and OpenGL, so I dunno.
            Probably because it also Targets PS4 and Xbox both of which have Radeon GPUs so they target the compatible subset of OpenGL instead of trying to optimise for Nvidia etc... its just optimized more generally.

            Comment


            • #16
              Originally posted by Marc Driftmeyer View Post

              And yet no one cares in the Windows world as games use DirectX and not OpenGL.
              Emulators tend to use OpenGL like CEMU, YUZU, and Citra. Which all run like crap on AMD in Windows due to poor OpenGL drivers. Run these emulators on Linux and the performance is far better.

              Comment


              • #17
                Originally posted by debianxfce View Post
                I tested NIR with the Superposition 1080p extreme benchmark and RX570:
                Code:
                Original R600_DEBUG=nir
                1867 1878 points
                13.97 14.05 avg fps
                No reason to use R600_DEBUG=nir.
                You should also log CPU usage during the run...

                Comment


                • #18
                  Originally posted by cb88 View Post

                  You should also log CPU usage during the run...
                  this. you don't even know if that testcase is CPU-bottlenecked for you and assumed wrong stuff as usual

                  Comment


                  • #19
                    Originally posted by nuetzel View Post

                    Note:
                    It was tested with Vega, here.
                    I see one little triangle corruption under UH with Polaris 20 (RX580). - Marek know that.
                    The above corruption is FIXED with current Mesa git.
                    Yes, this is SOLVED with NIR, even on Polaris. - GREAT.
                    (Have to bisect for the right commit.)

                    Marek's latest SDMA patches.
                    BUT sadly reliable _whole_ system hang under UH and UV with my Polaris 20 (Nitro+) => VM faults (I've to dig.)
                    Reverting the SDMA patches (1-4) on Polaris SOLVED this.

                    Comment


                    • #20
                      Can confirm. Those sdma patches immediately freeze the whole system. Even if it's just the desktop.

                      Comment

                      Working...
                      X