zzyzx (zzyzx.delete@this.zzyzx.sh) on May 24, 2022 3:18 pm wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on May 24, 2022 2:33 am wrote:
>
> > 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.

Certainly not something one would like people with minimal specs system needing to do.

> 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).

Is that linearly proportional to polling rate? So 16 ms for standard 125 Hz polling?

I do think people with 1000 Hz gaming mouse and a dual-core CPU are pretty small niche. That said, gaming mouse can be problematic in itself just because all the non-essential stuff that comes with it uses way too much CPU cycles.

But yeah, dual-core isn't necessarily OK for gaming just because it packs as many or more MIPS than 6 Jaguar cores. Bit like pair of 300 MHz CPUs were much better Gnome desktop experience twenty years ago than single 900 MHz CPU.

> 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.

Personally, I think using boosted priority threads is just asking for trouble. Maybe it's OK to have N in a system with 2N CPUs, but generally speaking one mostly needs the boosted priority when running out of CPU performance (on all cores). If that happens, things are bad anyway. Getting it right in such situation is not something I would even attempt on general purpose computer (consoles are somewhat different, mostly because their scheduling rules are usually simpler and one tends to notice soon, if some priority decision was less than optimal).

But yeah, I can imagine many games do boost priority on important threads. It sounds like a good idea, after all.

-JLarja