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

  • jrch2k8
    replied
    Originally posted by boffo View Post

    Not really, for example when I used to play TF2 with the weapons skins I always had stalling when switching weapons, since switching weapons in tf2 happens often, this reduces the average fps.
    well you are right but you asked benchmarks and in that case it won't affect the average much since benchmarks normally don't constantly re compute shaders that much often but even then it won't give more fps(your min and max will stay the same) just stabilize your average fps since it avoid frame tankings and stutters, so this is about smoothness not speed ups.

    Sure this can be benchmarked but it can require some creative thinking to make it visible in a graph and im not sure if PTS can measure it properly but michael should knot that better so i won't touch the benchmarks side of things here

    Leave a comment:


  • stqn
    replied
    Hopefully the next step is to save the compiled shaders on disk. I’m not a radeonsi gamer but with nvidia some games take several minutes to load when shaders need to be compiled (new game or driver version), even with a fast CPU.

    Leave a comment:


  • boffo
    replied
    Originally posted by jrch2k8 View Post

    this patch should not speed up any games, is not an optimization(normally at least), this avoid stalling the render thread while compile shaders over and over again during game play by just compiling shaders once and reuse from memory from that point onwards.

    So Before patch

    60fps -> 10fps(compiling) -> 60 fps -> 8 fps(compiling) -> 60fps ......

    After patch

    60 fps -> 10fps(compiling)-> 60fps -> 60fps(reusing) -> 60fpsfps -> 60 fps(reusing) .......

    note this patch don't cache GS shaders yet, so tessalation can still trash up your fps for compilation but should be a lot less than before
    Not really, for example when I used to play TF2 with the weapons skins I always had stalling when switching weapons, since switching weapons in tf2 happens often, this reduces the average fps.

    Leave a comment:


  • schmidtbag
    replied
    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.

    Leave a comment:


  • plonoma
    replied
    Originally posted by jrch2k8 View Post

    this patch should not speed up any games, is not an optimization(normally at least), this avoid stalling the render thread while compile shaders over and over again during game play by just compiling shaders once and reuse from memory from that point onwards.

    So Before patch

    60fps -> 10fps(compiling) -> 60 fps -> 8 fps(compiling) -> 60fps ......

    After patch

    60 fps -> 10fps(compiling)-> 60fps -> 60fps(reusing) -> 60fpsfps -> 60 fps(reusing) .......

    note this patch don't cache GS shaders yet, so tessalation can still trash up your fps for compilation but should be a lot less than before
    Very good explanation.
    Really illustrates clearly what the effect of the shader cache is.

    This patch is a fantastic improvement for the radeonsi driver.
    Eliminating stuttering will have a very good impact on fluency / stuttering and thus gameplay.
    Want to see the reusing extended to GS and CS as well.

    Still leaves us with the stalling from initial compilation.
    OpenGL could benefit greatly from async shader compilation and async GPU VRAM loading + shader cache by default.
    It sounds like decoupling shader compilation and caching/loading from the rendering pipeline/loop could do wonders for stable, fluent framerates with less stuttering.
    Last edited by plonoma; 23 February 2016, 01:55 PM.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by boffo View Post
    hmhmmh what about the benchmarks (on/off)?
    this patch should not speed up any games, is not an optimization(normally at least), this avoid stalling the render thread while compile shaders over and over again during game play by just compiling shaders once and reuse from memory from that point onwards.

    So Before patch

    60fps -> 10fps(compiling) -> 60 fps -> 8 fps(compiling) -> 60fps ......

    After patch

    60 fps -> 10fps(compiling)-> 60fps -> 60fps(reusing) -> 60fpsfps -> 60 fps(reusing) .......

    note this patch don't cache GS shaders yet, so tessalation can still trash up your fps for compilation but should be a lot less than before

    Leave a comment:


  • duby229
    replied
    Originally posted by atomsymbol

    I don't understand.

    How would you suggest to implement a content cache for OpenGL? I presume by "content" you mean textures.

    HD textures of Shadow of Mordor consume about 10 GB on disk. How are you suggesting to create a cache for that?
    I didn't suggest that at all. In fact I recognize that since the amount of physical data is small the risk of disk thrashing is minimal. However bandwidth isn't the only metric. Latency can be and often is more important. That's why I think it's a good idea. Avoid storage even if bandwidth isn't a concern.

    Leave a comment:


  • boffo
    replied
    hmhmmh what about the benchmarks (on/off)?

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by atomsymbol

    As far as I know, RadeonSI was already caching shaders in memory before this.

    What is the actual improvement of the binary shader cache?
    Ovbiously marek could explain better but basically every time a new effect or asset in games needed to be rendered you usually get a huge FPS drop while LLVM compiles the shaders to binary and in some games that could get really annoying really fast, since this patch many (not all yet) games just stutter the first time the shader is used and never again.

    So far for me X Rebirth, Civ 5 and Metro Redux(es) are way more FPS stable now(Pending Cities Skylines since a mod is crashing it after the update beside traffic++)

    Leave a comment:


  • FireBurn
    replied
    It wasn't any quieter than any other changes to Mesa - I'm guessing you just didn't spot it

    Leave a comment:

Working...
X