On Mon Nov 7 19:04:08 2022 +0000, Zebediah Figura wrote:
I don't know whether this patch makes sense or not, but we should probably at least try getting rid of the spinning first. I know Matteo was working on this; @Mystral, how's the progress on that work going?
I think I'm almost there, actually. I should be able to send a few MRs in the short term, barring new distractions :D
I haven't tested the games from the bugs referenced in this MR with my patches, or the patches on a single-core machine recently, but I expect them to help enough that there would be no need to explicitly disable CSMT on single-core machines. That said, I do happen to have a patch doing basically the same as this MR anyway (except I'm looking at dwNumberOfProcessors from GetSystemInfo()). The idea was that there isn't really anything to be gained by having a separate CS thread on a single-core machine, while the additional overhead would probably be non-negligible. FWIW, Windows happens (or happened, many years ago when I last looked into it) to do the same, not spawning a separate thread when e.g. forcing a single core. Admittedly, I didn't think about the Nvidia FPU control word issue, although that's arguably a driver bug and CSMT is an accidental workaround.
BTW,
Rewrite buffer map/unmap implementation so that it does not wait for the CS thread to finish (at least in some cases). I don't know how hard this would be, but it should help many other games as well.
That's largely already the case, which is also why it's now practical to just block instead of spinning when e.g. there are no CS commands in the queues. If there are still some cases where we wait when we could avoid to do so, we should "fix" those.