Announcement

Collapse
No announcement yet.

RadeonSI Quietly Landed A Shader Cache As A Last Feature For Mesa 11.2

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

  • geearf
    replied
    Originally posted by plonoma View Post

    Not everybody has an SSD. Many people still use rotational disk(s).
    You could use a tmp drive and sync it back to HDD on shutdown/restart. (Of course that demands enough RAM, even with a compress FS...)

    Leave a comment:


  • plonoma
    replied
    Originally posted by atomsymbol

    Do you mean latency on a rotational disk, not SSD? I have my home directory (and consequently the shader caches, such as ~/.AMD/GLCache) on an SSD.

    Since the moment I bought an SSD, latency isn't an issue in any application I am running - the CPU speed is now the limiting factor.

    Or can latency of the shader cache be an issue even on an SSD?
    Not everybody has an SSD. Many people still use rotational disk(s).
    Last edited by plonoma; 23 February 2016, 06:05 PM.

    Leave a comment:


  • LeJimster
    replied
    Ever since I've switched to Linux I've wondered why things weren't as smooth, with noticeable fps drops. Something I notice especially in The Talos Principle on loading a new level. This shader caching feature seems like the way forward and I appreciate all the work being put into it as it's this kind of thing that makes a big difference to immersion.

    Leave a comment:


  • duby229
    replied
    Originally posted by atomsymbol

    Do you mean latency on a rotational disk, not SSD? I have my home directory (and consequently the shader caches, such as ~/.AMD/GLCache) on an SSD.

    Since the moment I bought an SSD, latency isn't an issue in any application I am running - the CPU speed is now the limiting factor.

    Or can latency of the shader cache be an issue even on an SSD?
    I think it depends on how it's implemented. From what I read here and elsewhere it sounds like it would only be read from disk in case it isn't already in RAM. It'll only have that one time hit on reading the shader from disk. It that case it would certainly have much less latency than recompiling the shader.

    For SSD, yeah, they have much less latency than any HDD, but still are the slowest component in a computer. Compared to RAM SSD's are slow as dirt.

    Leave a comment:


  • theriddick
    replied
    XCOM2 is a good example of shader stutter, it has it in spades.

    Leave a comment:


  • pal666
    replied
    Originally posted by smitty3268 View Post
    This is only enabled if you have LLVM 3.8+.
    mesa in fedora 24 is built with llvm 3.8, so this one is covered

    Leave a comment:


  • duby229
    replied
    Originally posted by smitty3268 View Post
    Couple points.

    This is only enabled if you have LLVM 3.8+.

    This is not the same as a full-blown shader cache a la the proprietary drivers. It's more meant to be a way of working around the fact that the driver has to change shaders when various state changes are made in OpenGL, which is a consequence of the way radeon hardware works and interacts with OpenGL. Though it is a good first step towards a full shader cache, as there is now just 1 binary program compiled per shader rather than potentially multiple versions depending on different GL states.

    It would be simple to just start saving these drivers to the hard drive, but it probably makes more sense to come up with a solution that happens before the GLSL parser gets involved, as that is still pretty slow and wouldn't get bypassed.

    Some numbers and a far better explanation from Marek are available here: [URL="https://lists.freedesktop.org/archives/mesa-dev/2016-February/107737.html"]https://lists.freedesktop.org/archiv...ry/107737.html[/U

    So it should speed up load times in a lot of cases, in addition to hopefully keeping in-game stutters reduced.
    Ah! That make a lot of sense. So in this particular case the cache reduce latency by making certain a shader is already available when it gets re-used. And eventually once the disk cache gets implemented properly, once the shader is compiled the first time, even restarting the computer that shader will still be available. As long as the disk cache is being used as storage for the sake of storage it'll probably be fine.

    But I present The Old Republic Online as an example of how using a disk cache can seriously hurt performance. It's not a matter of bandwidth that hurts, it's latency.
    Last edited by duby229; 23 February 2016, 03:35 PM.

    Leave a comment:


  • marek
    replied
    Originally posted by schmidtbag View Post
    I'm guessing this won't have much of a measurable performance difference in benchmark averages, but it should definitely be noticeable to users during gameplay, which is great.
    I think that the whole work (not just the shader cache, but also the commits that remove shader compilation from draw calls) will help game benchmarks too.

    If a benchmark loads shaders before it starts benchmarking, the result will be that the shader compilation time will not affect the final result no matter how long the compile times are. If a benchmark needs 10 seconds to compile shaders, it means the benchmark will finish 10 seconds sooner from the start of the benchmarking.

    Unreal Engine (Borderlands 2, etc.) loads shaders before draw calls and drivers can't change that, but I noticed 40% of those shaders are duplicates. The shader cache in memory eliminates them, making even the first compilation look faster, and subsequent shader reloads almost instant.
    Last edited by marek; 23 February 2016, 04:17 PM.

    Leave a comment:


  • haplo602
    replied
    Originally posted by smitty3268 View Post
    Couple points.

    This is only enabled if you have LLVM 3.8+.

    This is not the same as a full-blown shader cache a la the proprietary drivers. It's more meant to be a way of working around the fact that the driver has to change shaders when various state changes are made in OpenGL, which is a consequence of the way radeon hardware works and interacts with OpenGL. Though it is a good first step towards a full shader cache.

    It would be simple to just start saving these drivers to the hard drive, but it probably makes more sense to come up with a solution that happens before the GLSL parser gets involved, as that is still pretty slow and wouldn't get bypassed.

    Some numbers and a far better explanation from Marek are available here: https://lists.freedesktop.org/archiv...ry/107737.html



    So it should speed up load times in a lot of cases, in addition to hopefully keeping in-game stutters reduced.
    Pretty much this. also it does NOT remove the performance hit when each shader is used for the first time. only reuses are cheaper. however it's a nice step forward.

    Leave a comment:


  • smitty3268
    replied
    Couple points.

    This is only enabled if you have LLVM 3.8+.

    This is not the same as a full-blown shader cache a la the proprietary drivers. It's more meant to be a way of working around the fact that the driver has to change shaders when various state changes are made in OpenGL, which is a consequence of the way radeon hardware works and interacts with OpenGL. Though it is a good first step towards a full shader cache, as there is now just 1 binary program compiled per shader rather than potentially multiple versions depending on different GL states.

    It would be simple to just start saving these drivers to the hard drive, but it probably makes more sense to come up with a solution that happens before the GLSL parser gets involved, as that is still pretty slow and wouldn't get bypassed.

    Some numbers and a far better explanation from Marek are available here: https://lists.freedesktop.org/archiv...ry/107737.html

    5) Performance of the shader cache
    The test is a short apitrace of Borderlands 2.
    Without the cache: GLSL link time = 18361 ms Driver compile time = 14510 ms
    With the cache: GLSL link time = 12576 ms Driver compile time = 8552 ms

    This leaves a lot to be desired, but it was expected. The TGSI compilation takes 41% less time, which means 41% of all TGSI shaders are duplicates. On average, linking GLSL shader programs (including the TGSI compilation) takes 31.5% less time.

    The compile times are still unacceptable and caching shaders on the disk appears to be a necessity. A radeonsi-only cache on the disk should be relatively easy with the current cache in memory, but 33% of the compilation time is not spent in radeonsi.
    So it should speed up load times in a lot of cases, in addition to hopefully keeping in-game stutters reduced.
    Last edited by smitty3268; 23 February 2016, 03:11 PM.

    Leave a comment:

Working...
X