Announcement

Collapse
No announcement yet.

Mesa 19.2 Picks Up The Radeon R300~R500 Series On-Disk OpenGL Shader Cache

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

  • Mesa 19.2 Picks Up The Radeon R300~R500 Series On-Disk OpenGL Shader Cache

    Phoronix: Mesa 19.2 Picks Up The Radeon R300~R500 Series On-Disk OpenGL Shader Cache

    Last week an on-disk GLSL shader cache was proposed for the vintage "R300g" open-source Gallium3D driver for this OpenGL code supporting through the Radeon X1000 (R500) series. That shader cache support has now been merged into Mesa 19.2...

    http://www.phoronix.com/scan.php?pag...he-Merged-19.2

  • #2
    It would be great to benchmark the three versions (without fixes, with the performance regression fix and with the shader cache). I actually tried SuperTuxKart yesterday on my Xpress 200M, but I couldn't get it past 2 fps at the absolute lowest settings (which, at that level, I believe doesn't even use shaders). Like you wrote, the problem is finding a shader-intensive game which runs well on these old GPUs.

    EDIT: It seems that ioquake3 has an OpenGL 2.x renderer. Maybe OpenArena is a good benchmark…?
    Last edited by HyperDrive; 06-12-2019, 09:27 AM.

    Comment


    • #3
      Hardware optimization is one of the added value in which Linux Os can excel.

      Comment


      • #4
        Minecraft runs surprisingly well on my Radeon 1950XTX. There is also Quake 4 or Doom 3 which is in the PTS.

        Comment


        • #5
          I had read comments in mailing list. It seems no one including patch author not even tested it due to lack of hardware. But Marek had merged it, hopefully at least he had tested it.

          Comment


          • #6
            Originally posted by yurikoles View Post
            I had read comments in mailing list. It seems no one including patch author not even tested it due to lack of hardware. But Marek had merged it, hopefully at least he had tested it.
            I have tested it, just haven't benchmarked it. It's not easy to find a shader-intensive workload which runs well on an Xpress 200M, and the shader cache mostly helps with lots of shader compile-use-discard cycles. I haven't tried my X1600 laptop yet, but I will, eventually (I'm also getting a laptop with an X700 soon). Unfortunately, a day only has 24 hours, and Mesa is not really my day job. 😉

            Comment


            • #7
              Originally posted by HyperDrive View Post
              Unfortunately, a day only has 24 hours, and Mesa is not really my day job. 😉
              I'm wannabe-mesa-dev here, but this low-level C code looks hard to me even with mine 8 years of Mobile Development experience.

              Comment


              • #8
                Originally posted by yurikoles View Post
                I'm wannabe-mesa-dev here, but this low-level C code looks hard to me even with mine 8 years of Mobile Development experience.
                You caused some very useful discussion on the mesa-git AUR PKGBUILD that I'm using. It helped me understand WTF was going on with the llvm build dependency in that PKGBUILD. (yay forcing llvm 9 minimal-git... solution: don't do that)

                At first I thought that was right, as usually you do want a newer llvm for mesa devel but in this case llvm 8 was the right thing to do. I was getting some (but not all) shaders miscompiled such that I was getting lighting/shadow corruption in several games using Vulkan natively and DXVK.

                So thanks for crying foul, I didn't know enough about that PKGBUILD at the time. (never encountered anything like that variable in the AUR). Now I really like that PKGBUILD, I make a few changes to the meson build options. Those helpers are pointless to me now.

                Comment


                • #9
                  I don't see what trying to benchmark that would achieve. It's more of a feely thing, as it depends on circumstances.

                  All I know is that whenever I change my Mesa and/or LLVM, shaders get recompiled when games are first used. What I do is load levels, wander and pan around for a bit until performance improves, then quit the game. On subsequent runs performance is better yet.

                  P.S. R9 380 Tonga hardware here, I don't mean to imply that I have tested R300-500 series.
                  Last edited by Grogan; 06-12-2019, 03:24 PM.

                  Comment


                  • #10
                    Originally posted by HyperDrive View Post
                    EDIT: It seems that ioquake3 has an OpenGL 2.x renderer. Maybe OpenArena is a good benchmark…?
                    I guess not. OpenArena crashes quite spectacularly at startup with a shader compilation error. Looks like it's requesting an OpenGL 3.2 core context and falling back to an OpenGL 2 context, but the shader fails to compile anyway (maybe it's too complex for the hardware?). In any case, Nexuiz runs fine (albeit slowly).

                    Comment

                    Working...
                    X