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

  • skeevy420
    replied
    Originally posted by CochainComplex View Post

    p.s.: Whats up with the frog nameing anyway Joshua Asthon is also making use of it. I know OT but is there any reason why frogs are going viral? Related to Pepe?
    Lol. I've always wondered that myself. I don't think there's any relation to Pepe.

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by skeevy420 View Post

    It has been a few months since I've used so I'm not 100% sure what has and hasn't changed since it's a rapidly changing project. For example, it was still one unified repo and didn't have Frogging-Family when I used it last.

    Best advice I have is to just make sure you have all the extra dependencies installed because you will play a bit of dependency hell until you figure you what you need and don't need based on how you configure everything...like making sure all the right stuff is installed for vkd3d before you compile wine or proton if you're gonna use vkd3d...
    Ok thank you. I think I first have to digg through the f(r)oggy mist to be able to compile it.


    p.s.: Whats up with the frog nameing anyway Joshua Asthon is also making use of it. I know OT but is there any reason why frogs are going viral? Related to Pepe?

    Leave a comment:


  • skeevy420
    replied
    Originally posted by CochainComplex View Post

    I wanted to go this route as well l thanks for sharing. Any strange points to be aware of?
    It has been a few months since I've used so I'm not 100% sure what has and hasn't changed since it's a rapidly changing project. For example, it was still one unified repo and didn't have Frogging-Family when I used it last.

    Best advice I have is to just make sure you have all the extra dependencies installed because you will play a bit of dependency hell until you figure you what you need and don't need based on how you configure everything...like making sure all the right stuff is installed for vkd3d before you compile wine or proton if you're gonna use vkd3d...

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by skeevy420 View Post

    I have, but only via TK-Glitch's scripts.
    I wanted to go this route as well l thanks for sharing. Any strange points to be aware of?

    Leave a comment:


  • skeevy420
    replied
    Originally posted by CochainComplex View Post

    One more reason to compile proton by oneself. I have never done it - maybe this could be the right time. PGO !!!!
    I have, but only via TK-Glitch's scripts.

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by skeevy420 View Post

    Probably, eventually, maybe

    I haven't actually looked at how it is written; just what is said in the release notes where they say 1/4 of the threads available. Based on their description, it sounds more like a hardcoded value over something we can set.
    One more reason to compile proton by oneself. I have never done it - maybe this could be the right time. PGO !!!!

    Leave a comment:


  • skeevy420
    replied
    Originally posted by CochainComplex View Post

    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.
    Probably, eventually, maybe

    I haven't actually looked at how it is written; just what is said in the release notes where they say 1/4 of the threads available. Based on their description, it sounds more like a hardcoded value over something we can set.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • skeevy420
    replied
    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).

    Leave a comment:

Working...
X