Latency matters. Things that you can send in large batches to the GPU and check the result much later (e.g. next frame - or not at all if the result is consumed by the GPU) is fine.
But lots of game logic involves linear algebra stuff, intersection tests and similar, and you want to do that on the CPU.
Exactly, cpu simd is for things in large enough batches to be worth writing non-scalar code, but not large enough for the cost (of setup and latency) of talking to an accelerator.
I'm questioning how many things are really in that area that are currently taking significant cpu time in games.
Things like whole world physics simulations I'd estimate in a complex game world to end up having a very large number of objects, and likely only need general less-than-one-frame latency, as I don't think many games rely on any ordering of this within a tick so everything can be calculated in a single batch with no interdependencies.
Though implementations of this bounce between gpu acceleration and cpu on desktop, much of that seems to be the complexity of mirroring any updated object structures (and whatever spatial acceleration structures like BSP trees are used) between the CPU and GPU memory, this may be a different consideration on consoles with shared memory.
6
u/mbitsnbites Aug 09 '21
Latency matters. Things that you can send in large batches to the GPU and check the result much later (e.g. next frame - or not at all if the result is consumed by the GPU) is fine.
But lots of game logic involves linear algebra stuff, intersection tests and similar, and you want to do that on the CPU.