By: zzyzx (zzyzx.delete@this.zzyzx.sh), May 24, 2022 3:18 pm
Room: Moderated Discussions
Jukka Larja (roskakori2006.delete@this.gmail.com) on May 24, 2022 2:33 am wrote:
> What is an UMD thread?
User-Mode Driver, sorry; the graphics driver.
> Sure, it's certainly possible to mess things up, if there just isn't enough CPU time available.
> My point was just that a game that runs on PS4 doesn't have all that much CPU power available,
> even if it makes full use of all cores available (which it seems very few games do).
>
> Vermintide 2, however, doesn't seem to be such game, based on release
> dates. Seems that it was ported to consoles after PC release.
>
> We actually had (or have, the game's still available) similar issue in Trine 2 on Linux,
> where X saturated a dual-core CPU so badly that main thread had no time to run, causing
> crazy stuttering (I don't think average FPS was good either, though). I think we ended
> up just limiting by default to 30 FPS. We didn't have much budget for that port.
Yeah, appropriate framerate caps will do it, that's just awkward.
> Yeah, but that only happens if there isn't enough CPU power available in the first place. Or if
> the game is coded in a brain dead[1] way and does some busy waiting or something like that.
>
> [1] Not really brain dead necessarily. It can be completely OK business decision to require quad-core
> and not care about anything below, even if the reasons from technological point of view are stupid.
>
> -JLarja
It's a bit worse than that. IO_DT doesn't have to be blocked indefinitely for input to be lost, just for 2 ms at a time as I understand it (for 1000 Hz polling). There may not be many games that go to 100% CPU utilization if given the chance, but there's no shortage of them with blocks of work that can saturate 8-12T for 2+ ms every frame (command buffer build if nothing else). Because of that, limiting framerate doesn't generally even fix it. Making it even worse, Win10's scheduler misses a lot of cross-core scheduling opportunities, so it's common for IO_DT to get blocked despite a bit of CPU time being actually left over by the game.
I have no idea what perfect game threading would even look like under those constraints. Riot appears to have gotten fed up enough with this (for Valorant) to replace something in the kernel to make earlier buffering possible, which is at least as scary as it is cool.
> What is an UMD thread?
User-Mode Driver, sorry; the graphics driver.
> Sure, it's certainly possible to mess things up, if there just isn't enough CPU time available.
> My point was just that a game that runs on PS4 doesn't have all that much CPU power available,
> even if it makes full use of all cores available (which it seems very few games do).
>
> Vermintide 2, however, doesn't seem to be such game, based on release
> dates. Seems that it was ported to consoles after PC release.
>
> We actually had (or have, the game's still available) similar issue in Trine 2 on Linux,
> where X saturated a dual-core CPU so badly that main thread had no time to run, causing
> crazy stuttering (I don't think average FPS was good either, though). I think we ended
> up just limiting by default to 30 FPS. We didn't have much budget for that port.
Yeah, appropriate framerate caps will do it, that's just awkward.
> Yeah, but that only happens if there isn't enough CPU power available in the first place. Or if
> the game is coded in a brain dead[1] way and does some busy waiting or something like that.
>
> [1] Not really brain dead necessarily. It can be completely OK business decision to require quad-core
> and not care about anything below, even if the reasons from technological point of view are stupid.
>
> -JLarja
It's a bit worse than that. IO_DT doesn't have to be blocked indefinitely for input to be lost, just for 2 ms at a time as I understand it (for 1000 Hz polling). There may not be many games that go to 100% CPU utilization if given the chance, but there's no shortage of them with blocks of work that can saturate 8-12T for 2+ ms every frame (command buffer build if nothing else). Because of that, limiting framerate doesn't generally even fix it. Making it even worse, Win10's scheduler misses a lot of cross-core scheduling opportunities, so it's common for IO_DT to get blocked despite a bit of CPU time being actually left over by the game.
I have no idea what perfect game threading would even look like under those constraints. Riot appears to have gotten fed up enough with this (for Valorant) to replace something in the kernel to make earlier buffering possible, which is at least as scary as it is cool.