Announcement

Collapse
No announcement yet.

Mesa's Shader Cache Is In The Process Of Landing

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

  • #11
    Originally posted by log0 View Post
    I think it might be worth to look into what browser guys are doing.

    Something like a really fast first time quick non-optimised compilation, plus a full optimisation pass done asynchronously.
    I'm told Chrome implements a shader cache.
    Free Software Developer .:. Mesa and Xorg
    Opinions expressed in these forum posts are my own.

    Comment


    • #12
      Originally posted by Kayden View Post
      I'm told Chrome implements a shader cache.
      I am talking about reducing first time stutter. Nothing speaks against combining it with a cache.

      Comment


      • #13
        Originally posted by Remdul View Post
        It depends. If the game/app compiles shaders on the fly, there may still be stutter, and there's little a driver can do about that. When apps are done right, all shader permutations should be pre-compiled at load time though (in my engines I render just a few pixels with each shader at load time just to ensure the driver doesn't cheat and defer compilation/linking). But for (NV and other vendors) that already cache, there will also be stutter in that situation (depending on raw compilation speed, which may vary across vendors). Don't forget there was a time when NV re-compiled shaders on the fly when a uniform value was updated (I think in cases of branching on older 'pre-branching' hardware), this was obviously bad for performance but still surprisingly acceptable (IMO). Most GLSL compilers are really fast by now. It is probably only the big, complex shaders with lots of branching that will should stutter when compiled on the fly.

        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.


        I do have a few concerns though. HDD latency is pretty close to what would be noticable on screen. Once the code is pre-compiled and stored on disk, those shaders will have to be loaded eventually. To avoid disk latency, (even on idle disks) this thing is going to need prediction and prefetch logic to make sure that shaders are in RAM when they are needed. That seems like it's going to be per application dependent.

        It's not the bandwidth of the drive I'm worried about, it's the latency.
        Last edited by duby229; 17 January 2015, 08:58 AM.

        Comment


        • #14
          Shader cache is there to help with Cpu overhead and not anything else. If you all like less latency buy n SSD.

          Comment


          • #15
            Originally posted by artivision View Post
            Shader cache is there to help with Cpu overhead and not anything else. If you all like less latency buy n SSD.
            Of course you're right, but that can't be the advice devs give to noobs. Most people won't, but they'll still be pissed when they perceive that latency without having any idea what is causing it.

            Comment


            • #16
              Originally posted by duby229 View Post
              HDD latency
              does not matter. it will be kept in page cache

              Comment


              • #17
                Originally posted by duby229 View Post
                Of course you're right, but that can't be the advice devs give to noobs. Most people won't, but they'll still be pissed when they perceive that latency without having any idea what is causing it.
                No worries they will simply blame AMD.
                Those who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
                Ben Franklin 1755

                Comment


                • #18
                  Originally posted by pal666 View Post
                  does not matter. it will be kept in page cache
                  OK, It shouldn't be a problem then. That logic is pretty good, has been for a long time. Cool.

                  Comment


                  • #19
                    Oh, more swapping.
                    I admit that I have no clue about the average byte size of what is to be done there but system RAM instead of HDD would sound better. HDDs tend to have a certain latency in response.
                    Ah, wait, that was intel tech. They don't have dedicated VRAM and use system RAM already. Hmm.

                    Where is that shader cache located? Do they put it in a specific file or write to swap partition? And wasn't SHA-1 officially not secure anymore? Though I guess speed counts here far more than hash collision safety. Do modern CPUs also support SHA-1 hardware acceleration?
                    Not totally sure about caching of that in general, too. In theory it might work and give you some advantages here and there but I also saw caching stuff go wrong. Okay, that was mainly IconCache on Windows, though.
                    I sometimes saw that back on Windows with blob drivers (nv or ati, can't remember). Sometimes a semi garbled image would be displayed where I could recognize an application that I had run some time ago and there was still something stuck somewhere. Might have been a somehow cached image. But it shouldn't be displayed on the start of a different program.
                    Stop TCPA, stupid software patents and corrupt politicians!

                    Comment


                    • #20
                      Well, it would be unlikely that any pages would be swapped out. I doubt there would be any swapping.

                      Comment

                      Working...
                      X