Announcement

Collapse
No announcement yet.

Mesa's Shader Cache Is In The Process Of Landing

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

  • #31
    Damn edit limit...

    I looked at my old benchmarks but take them with a grain of salt as the guys from intel wanted to optimize that some more:
    - You get more speedup when ~/.cache/mesa is located on a SSD rather than a HDD.
    - There's no difference between having ~/.cache/mesa on a SSD or a ramdisc (tmpfs).
    - The page cache gives a large speedup no matter what media ~/.cache/mesa is on. Beware that in real-world situations the needed shaders most likely aren't in the page cache (except you restart a game after it crashed, for example).

    //EDIT: Yes, that means the page cache is much faster than tmpfs... Maybe a kernel dev should look into this?

    //EDIT?: I neither work for AMD nor Intel.
    Last edited by V10lator; 18 January 2015, 05:41 AM.

    Comment


    • #32
      Originally posted by TAXI View Post
      Also no. Why not? Well, there's already a in memory shader cache handling that. The on-disc cache will speedup the first loading of a shader only (read: Game and/or level loading) and even there the speedup isn't as high as you would expect it to be.
      Many games are badly written and pass shaders during runtime. New shaders, so the memory cache doesn't help, but they might be on the hd cache from a previous run. In which case, if the HD seek overhead is more than the compile time, it will increase stutters.

      Comment


      • #33
        Originally posted by TAXI View Post
        Yes, I was one of the guys testing it on AMD hardware.
        Where is that code, i would like to test too? Or you talking about fglrx?

        Comment


        • #34
          Originally posted by TAXI View Post
          No. Also no. Why not? Well, there's already a in memory shader cache handling that. The on-disc cache will speedup the first loading of a shader only (read: Game and/or level loading) and even there the speedup isn't as high as you would expect it to be.
          So? In order to generate the in-memory cache, you need to compile the shaders first. Loading from disk is faster. For games that precompile all shaders, yes, only the loading time will change. For games I care about (UE4), where they are compiled on the fly, it will keep the stutters down. Right now I'm using NVIDIA drivers and there are initial stutters after each game update, and after that it works smoothly. Without the cache there would be initial stutters each time the game is reloaded.

          Comment


          • #35
            Originally posted by Remdul View Post
            I wonder why SHA-1 was chosen over MD5? The latter might be that wee bit faster that might hide any remaining stutter to disappear in natural framerate fluctuations. I don't think collisions are an issue given the typical nature of GLSL code (and neither is security). I guess typical shaders aren't that much data to hash, so the performance difference may be lost in the overhead.
            It's pretty ridiculous to use any kind of crytographic hashing for this, as you can get an order of magnitude better performance and much simpler code by using a pure hashing function like murmur, not to mention avoiding all the dependencies.

            It looks like the dev just wanted to copy/paste code from the xserver, and it uses sha1.

            Comment


            • #36
              Originally posted by curaga View Post
              Many games are badly written and pass shaders during runtime. New shaders, so the memory cache doesn't help, but they might be on the hd cache from a previous run. In which case, if the HD seek overhead is more than the compile time, it will increase stutters.
              True, but then again in my tests there was almost no difference with faster seek times, L4D2 loading:

              - Empty cache: 54 secs
              - Cache on HDD: 52 secs
              - Cache on SSD: 48 secs
              - Cache on ramdisk: 48 sec

              As you see there's 2 seconds difference between no (empty) cache and HDD, 4 seconds difference between HDD and SSD and zero difference between SSD and ramdisk (which is somehow weird). Keep in mind that these results are for many shaders, streamed-in shaders will most liely see a smaller speedup. Anyway these results are around 6/7 months old, so things might me better now.

              Originally posted by dungeon View Post
              Where is that code, i would like to test too? Or you talking about fglrx?
              It was on http://cgit.freedesktop.org/~tpalli/...h=l4d2_testing - As this branch doesn't exits anymore I don't know where to find it atm, sorry.

              //EDIT: Forgot the result in page cache, which should be similar to ramdisk but beats it by 7! seconds: 41 secs.
              Last edited by V10lator; 18 January 2015, 08:34 PM.

              Comment


              • #37
                Valve's shaders are some of the most optimized shaders on linux, and it did speed them up a bit. Other, less well optimized shaders could see much greater gains.

                Comment


                • #38
                  Originally posted by TAXI View Post
                  True, but then again in my tests there was almost no difference with faster seek times, L4D2 loading:
                  nice
                  did you do a echo 3 > /proc/sys/vm/drop_caches before every test ?

                  Comment

                  Working...
                  X