Announcement

Collapse
No announcement yet.

Steam Ironing Out Shader Pre-Caching For Helping Game Load Times, Stuttering

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

  • Steam Ironing Out Shader Pre-Caching For Helping Game Load Times, Stuttering

    Phoronix: Steam Ironing Out Shader Pre-Caching For Helping Game Load Times, Stuttering

    Valve developers have been working on Vulkan shader pre-caching with their latest Steam client betas to help in allowing Vulkan/SPIR-V shaders to compile ahead of time, letting them be pre-cached on disk to allow for quicker game load times and any stuttering for games that otherwise would be compiling the shaders on-demand during gameplay, especially under Steam Play...

    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
    Hmm. Makes me wonder what kinds of systems they're testing on if it's only 1/4 of the threads available. On my system, 16 threads, it could be upped to 1/2 to 3/4 since most games use 1-4 threads with a few being able to use more if they're there.

    I hope that's just early work and it'll be updated with a method to saturate threads the game isn't using minus one for beefier systems.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      Hmm. Makes me wonder what kinds of systems they're testing on if it's only 1/4 of the threads available. On my system, 16 threads, it could be upped to 1/2 to 3/4 since most games use 1-4 threads with a few being able to use more if they're there.
      I think 1/4 of threads makes sense. You don't want so many that low-end systems will get bottlenecked by this process (otherwise there will be no performance gain), but you don't want so few that people with high-end systems could have untapped performance.
      Games are steadily using more threads, and don't forget Proton has some CPU overhead too.
      I hope that's just early work and it'll be updated with a method to saturate threads the game isn't using minus one for beefier systems.
      Well, that's kinda like buying a 500HP sportscar and hoping speed limits increase so you can take advantage of its speed (yeah yeah Germany I know about the Autobahn... that's an exception). I get why you want to unleash the power that you bought, but unless you take it on a track, it seems like you just spent more money on something better than what you really needed.
      Normally I'd argue 8c/16t is overkill for gamers, but on Linux, there is enough additional overhead that I'm sure it's a healthy amount.
      For AMD users, keep in mind that the SMT threads are really only beneficial for alike threads. AMD's SMT method is optimal for parallelization, not multitasking. Games tend to multitask, rather than split up a complex workload into many threads. So for example, you might have one thread for in-game logic, another thread to calculate physics, another thread that handles what gets rendered, etc. These are calculated totally differently, so if 2 of these different threads run on the same core, you won't hardly get any extra performance out of SMT. That being said, 8c/16t for Linux is actually a pretty good amount, because (as long as the scheduler is smart enough) you should never have to worry about dissimilar threads running on the same core.

      Comment


      • #4
        Can anybody qualified please shed light on whether D3D12 -> Vulkan mapping can happen without any additional shader compile stutter?

        Comment


        • #5
          I wonder if that's why Warhammer 2 suddenly got smoother for me. I assumed it was some AMD kernel or Mesa change, or a change in the game itself.
          ​​​​​

          Comment


          • #6
            i ve activated this beta feature a couple of days ago,
            then the next day i launched quack champions (a stutterfest when loading texturethings), i saw fossilize use all of my cores (12) for almost 5 minutes before starting the game. since then the game starts faster and is silky smooth. works for me!

            Comment


            • #7
              if the games support at least 16 trheats it will be great, like with consoles, I can imagine low end gpu with good cpu performing much better

              Comment


              • #8
                Originally posted by schmidtbag View Post
                I think 1/4 of threads makes sense. You don't want so many that low-end systems will get bottlenecked by this process (otherwise there will be no performance gain), but you don't want so few that people with high-end systems could have untapped performance.
                Games are steadily using more threads, and don't forget Proton has some CPU overhead too.

                Well, that's kinda like buying a 500HP sportscar and hoping speed limits increase so you can take advantage of its speed (yeah yeah Germany I know about the Autobahn... that's an exception). I get why you want to unleash the power that you bought, but unless you take it on a track, it seems like you just spent more money on something better than what you really needed.
                Normally I'd argue 8c/16t is overkill for gamers, but on Linux, there is enough additional overhead that I'm sure it's a healthy amount.
                For AMD users, keep in mind that the SMT threads are really only beneficial for alike threads. AMD's SMT method is optimal for parallelization, not multitasking. Games tend to multitask, rather than split up a complex workload into many threads. So for example, you might have one thread for in-game logic, another thread to calculate physics, another thread that handles what gets rendered, etc. These are calculated totally differently, so if 2 of these different threads run on the same core, you won't hardly get any extra performance out of SMT. That being said, 8c/16t for Linux is actually a pretty good amount, because (as long as the scheduler is smart enough) you should never have to worry about dissimilar threads running on the same core.
                I just mean something smarter and more dynamic than nproc/4. While I agree that 1/4 is a perfectly fine generic value for testing purposes, depending on how well it scales, however, something based on threads available and threads used could be more useful (high end desktops, workstations, mulit-seat setups, and server platforms like Stadia).

                Comment


                • #9
                  Shader compilation seems to be an issue. Is this a Vulkan specific problem or general? I know that for most titles you get stutter via proton at least initially and with some it's pretty drastic and they almost always say it's due to shader caching.

                  Comment


                  • #10
                    Originally posted by skeevy420 View Post

                    I just mean something smarter and more dynamic than nproc/4. While I agree that 1/4 is a perfectly fine generic value for testing purposes, depending on how well it scales, however, something based on threads available and threads used could be more useful (high end desktops, workstations, mulit-seat setups, and server platforms like Stadia).
                    Maybe I have misse something. But wouldnt it be possible to default 1/4 and use some PROTON_NAMEME flag to customize the behaviour. But I guess this might requiere a recompilation which then does not work as a startup env flag.

                    Comment

                    Working...
                    X