To be clear, I said typically it's not a hardware issue; looking at historical precedent, we see tons of high powered rigs suffer from similar hitching none of which should be attributable to the hardware.It's the suggestion that looking at something on screen and attributing it to software or hardware. It could be bad code, it could be the hardware is simply not fast enough to do what the software is demanding. There's no way you can tell without deeper analysis of code and performance tools. Something not executing quickly enough to hit 16ms and being predictable/reproducible can equally be bad code or hardware choking. ¯\_(ツ)_/¯
The video shows a brief halting of frame rate, going from 60 and diving to 30, visually you can see the game pause briefly. Therefore, something not executing quickly enough to hit 16ms would hit 17ms or 18ms, which is 58 and 56 fps.
Typically GPUs that are running behind schedule will do so gradually, sharp dips are often indicative of a complete stall. You shouldn't expect the GPU to run 16+ms over to put up text.
We've had these types of hitching issues around forever, it has not favoured higher clocks vs wider GPUs. I believe the whole fast/narrow and wide/slow is a complete misnomer. There's virtually no such thing, having less compute units has no direct correlation to how fast you can run your chip. You can have the widest chip also run insanely fast if you're willing to pay the premium for that type of yield and cooling. This is like saying the 5700 is fast/narrow vs the 5700XT being wide/slow. The 5700XT is both faster and wider.
I believe this narrative needs tuning. There is imo, extreme overemphasis on what clockspeed is capable of. You have a better argument that the XSX is unable to make full use of it's CUs due to the imbalance of compute to fixed function units, is a much more probable argument than clock speed alone being the determining factor why PS5 can outperform XSX on the titles reviewed so far. In which the reality of the problem isn't that PS5 is fast and narrow, and XSX is wide and slow; it's not wide enough, as it's only widened only 1 part of it's hardware and not everything uniformly.
When it comes to complete compute workloads, in which all work is heavily parallelized, clock speed is very unlikely to achieve anything significantly more than computational throughput. Cache speed etc are unlikely to play a relevant factor here between the two.
The 24% gap in compute fed by 24% memory bandwidth will hold in these scenarios.
edit: thanks Alex! Settles this discussion. Nothing to add really. Interesting to see the bottlenecks all over though, curious to see where the bottleneck is in the hardware in those situations.
Last edited: