zzyzx (zzyzx.delete@this.zzyzx.sh) on May 23, 2022 11:02 pm wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on May 23, 2022 12:59 am wrote:
> > PC games have rather large scale in CPU needs these days. Some people will want to game on their 160
> > Hz (or even more) monitor, while recommended system should likely run at 60 and minimum around 30 FPS.
> > If you start by presuming 30 FPS is OK and someone who just wants to run the game regardless of minimum
> > specs will be happy with 20-25 FPS, dropping from four cores to two isn't all that crazy anymore.
> >
> > A typical target for modern game would be PS4, which is about 6 Jaguar cores at 1.6 Ghz. That's not
> > many when translated to 4.2 GHz Comet Lake cores. A typical gamer may want to have a browser, some
> > chat programs, maybe some VoIP running. Low-end gamer knows to close down everything but the game.
>
> For sure, the total ability in those 2C isn't bad at all. If you could map all the work onto it perfectly,
> it'd be enough, the work just doesn't always map onto it anywhere close to perfectly.
>
> Take Vermintide 2 as an example (Bitsquid/Stingray has very straightforward and well-documented yet
> reasonably typical threading and Vermintide 2 lets you adjust both the worker count and DX11 vs DX12).
> Most of the game's per-frame work happens on main, render main, a single worker pool, and situationally
> UMD threads. There's one very active UMD thread with an AMD GPU and DX11, and zero with an AMD GPU
> and DX12. With the default settings of 2 workers and DX11, the contention just makes a terrible mess
> of stutter and latency, even if average framerates are decent. 1 worker and DX11 simply isn't fast
> enough. 2 workers and DX12 is pretty good, since it gets the UMD thread out of the way.
>
> If the total performance available is already marginal it doesn't take much of this trouble to make it unplayable,
> and I'd really hate to try to dial all that in with multiple worker pools and for any graphics driver.

What is an UMD thread?

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.

> Possibly the most "fun" thing I've run into along these lines is a priority inversion in Windows' input handling.
> csrss.exe's IO_DT thread has to run on time for each mouse poll or input gets lost. IO_DT itself is appropriately
> prio 16, but regularly waits on prio 8 threads of other programs interested in input (overlays / PTT for VoIP
> / etc, including graphics driver stuff you can't simply turn off). If a game does threaded work at boosted
> prio, it can block those prio 8 threads and therefore IO_DT, making a mess of its own input.

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