Announcement

Collapse
No announcement yet.

Intel's Mesa On-Disk Shader Cache Maturing, Radeon Devs Not Yet Convinced

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

  • Intel's Mesa On-Disk Shader Cache Maturing, Radeon Devs Not Yet Convinced

    Phoronix: Intel's Mesa On-Disk Shader Cache Maturing, Radeon Devs Not Yet Convinced

    For quite a while now Intel and Collabora developers have been working on an on-disk shader cache similar to what's offered by the NVIDIA proprietary driver for allowing GLSL shaders to be compiled and then cached on-disk, making it quicker to load the shaders in the future. It's looking like the Intel shader cache implementation may soon be ready for Git...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I'm still leery about touching storage. If it takes longer to compile a shader than it does to read it from disk, then it can help.. But I'm not convinced that'll happen every time. I think it needs to be extremely concious of overall latency and be very selective.

    Comment


    • #3
      On Windows, the nvidia shader cache cuts loading time for Elite: Dangerous from 30 seconds to 3 seconds. So there are definitely games out there that benefit from this.

      Comment


      • #4
        Originally posted by duby229 View Post
        I'm still leery about touching storage. If it takes longer to compile a shader than it does to read it from disk, then it can help.. But I'm not convinced that'll happen every time. I think it needs to be extremely concious of overall latency and be very selective.
        It's all part of a Intel plan to keep their iGPUs not competitive for gaming.

        Comment


        • #5
          Originally posted by duby229 View Post
          I'm still leery about touching storage. If it takes longer to compile a shader than it does to read it from disk, then it can help.. But I'm not convinced that'll happen every time. I think it needs to be extremely concious of overall latency and be very selective.
          Well nVidia and AMD blobs has this feature, it load things much faster... it is disableable too, so if you have some concern and wanna be slow just disable it

          Comment


          • #6
            Originally posted by duby229 View Post
            I'm still leery about touching storage. If it takes longer to compile a shader than it does to read it from disk, then it can help.. But I'm not convinced that'll happen every time. I think it needs to be extremely concious of overall latency and be very selective.
            Only real difference is doing sha1 hash prior to parsing shader file (negligible performance hit) and one time load of shader cache lookup table from hdd (on ssd negligible, on hdd matter of reading few disk blocks at most). If you campare loading shader from IR cache (generally few disk blocks) and operation of shader parsing and compilation then shader cache wins hands down every time (except for maybe extreme cases of heavy IO load and extremely simple shader).
            One difference ofcourse being state after driver update (that changed intermediate representation thus invalidating shader cache), when it might make it slightly slower.

            Many games actually try to prevent "stutter effect" of dynamic shader loading by compiling "everything" every time (new game instance), example of this is dota2. First game load takes _a_lot_ longer than consecutive loads and much of this time is spent on compiling GLSL shaders (also mmaping big .vpk files containing ingame stuff).

            Basically, worst case stuff might take few miliseconds longer, best case you can see improvements in load times in seconds (as compared to static shader compilation each runtime). Even trivial GLSL shaders undergo 2-pass parsing.

            Anyways, looked at V1 of these patches some time ago and while code itself wasn't all that clean, it was fairly straight forward and trivial.
            The problem with it is that IR differs across mesa supported hardware somewhat and they all have their quirks (or at least V1 patches were riddled with workarounds).
            Last edited by Guest; 13 July 2016, 09:00 AM.

            Comment


            • #7
              Originally posted by tpruzina View Post

              Only real difference is doing sha1 hash prior to parsing shader file (negligible performance hit) and one time load of shader cache lookup table from hdd (on ssd negligible, on hdd matter of reading few disk blocks at most). If you campare loading shader from IR cache (generally few disk blocks) and operation of shader parsing and compilation then shader cache wins hands down every time (except for maybe extreme cases of heavy IO load and extremely simple shader).
              One difference ofcourse being state after driver update (that changed intermediate representation thus invalidating shader cache), when it might make it slightly slower.

              Many games actually try to prevent "stutter effect" of dynamic shader loading by compiling "everything" every time (new game instance), example of this is dota2. First game load takes _a_lot_ longer than consecutive loads and much of this time is spent on compiling GLSL shaders (also mmaping big .vpk files containing ingame stuff).

              Basically, worst case stuff might take few miliseconds longer, best case you can see improvements in load times in seconds (as compared to static shader compilation each runtime). Even trivial GLSL shaders undergo 2-pass parsing.

              Anyways, looked at V1 of these patches some time ago and while code itself wasn't all that clean, it was fairly straight forward and trivial.
              The problem with it is that IR differs across mesa supported hardware somewhat and they all have their quirks (or at least V1 patches were riddled with workarounds).
              Thanks for explaining it better. There are a few games I played where I felt something that could be called stuttering, but I had assumed (perhaps wrongly) that it was the game engine bottlenecking on loading in-game content from disk. It's usually evident by the disk LED thrashing at the moment of the stutter. I'm not convinced a shader cache can help those micro-freezes.

              Comment


              • #8
                Try Borderlans 2 if you have it - i think that is worse example, that stutter and has CPU bottleneck. It wants both shader cache and threadedGL, to be smooth and to perform normal.

                Comment


                • #9
                  Originally posted by RealNC View Post
                  On Windows, the nvidia shader cache cuts loading time for Elite: Dangerous from 30 seconds to 3 seconds. So there are definitely games out there that benefit from this.
                  for ssd or hdd?

                  Comment


                  • #10
                    I personally see no harm in this, but, it should be optional. For some devices, particularly ones with SoCs, some users might not have storage they're willing to spare, or might not have storage that's fast enough to benefit from this. Furthermore, how does the cleanup work? If the cache is permanent, that data will add up quickly over time, but if it's too short-lived then it doesn't really benefit users that much.

                    Personally, I'm much more interested in Marek's approach of making it multi-threading. Mesa currently seems to be very bottlenecked by the CPU. These days, if you have a single-core CPU, chances are GPU performance is not a priority.

                    Comment

                    Working...
                    X