Digital Foundry Article Technical Discussion [2021]

[function]

Series consoles are an outlier in the age of dynamic clocks to better utilize thermals and power usage for specific workloads. The ability for the series x to utilize its theoretical performance is going to be far tougher, especially for titles not built from the ground up with that particular SKU. PS5s dynamic clock setup makes it far more flexible for a broader range of game workloads so the discrepancies in head to heads will likely favor the PS5 more often.

That's a bit of an oversimplification IMO.

The PS5's solution allows it to get higher performance than it would over the same silicon at a fixed performance level. How it performs compared to another piece of silicon at a fixed performance level (in hardware terms) depends on that piece of hardware and the software running on them both.

The other way of looking at the PS5 is that as utilisation of the CUs and the CPU increase, typically available GPU performance will reduce compared to a fixed performance unit. That's not a flaw, it's simply what's to be expected.

Sony's solution is extremely effective, but the first year or two of games, which are less likely to run into power limits (or do so to a smaller extent), will show the best performance relative to fixed clocks.

I've said this before, but Sony's solution is brilliant because early software (particularly the first couple of years) will probably benefit most relative to Xbox, and it's pretty much the first couple of years that matter most.

Four years from now, probably no-one will actually care if Ray Tracing heavy games run at a 10% higher dynamic res (or whatever) on one platform rather than another.

 

[Dictator]

That's a bit of an oversimplification IMO.

The PS5's solution allows it to get higher performance than it would over the same silicon at a fixed performance level. How it performs compared to another piece of silicon at a fixed performance level (in hardware terms) depends on that piece of hardware and the software running on them both.

The other way of looking at the PS5 is that as utilisation of the CUs and the CPU increase, typically available GPU performance will reduce compared to a fixed performance unit. That's not a flaw, it's simply what's to be expected.

Sony's solution is extremely effective, but the first year or two of games, which are less likely to run into power limits (or do so to a smaller extent), will show the best performance relative to fixed clocks.

I've said this before, but Sony's solution is brilliant because early software (particularly the first couple of years) will probably benefit most relative to Xbox, and it's pretty much the first couple of years that matter most.

Four years from now, probably no-one will actually care if Ray Tracing heavy games run at a 10% higher dynamic res (or whatever) on one platform rather than another.

Interesting. Today's Video should get an interesting response then! I at least think it is going live today.. .

 

[goonergaz]

the haptic feedback for Control on Xbox is fairly involved as well, probably not as good as the HD level of quality that DS5 has, but it's made full use of the xbox controller.
For me, if stuttering is resolved, Quick Resume would take precedence. Control is very quick resume friendly, you can pull it off anywhere which is pretty nice given how far some checkpoints can be and some bosses can be frustrating.

1) Haptic is better
2) Hitching not confirmed to be being fixed
3) PS5 can give QR to one game (which might expand)

But each to their own.

 

[snc]

That's a bit of an oversimplification IMO.

The PS5's solution allows it to get higher performance than it would over the same silicon at a fixed performance level. How it performs compared to another piece of silicon at a fixed performance level (in hardware terms) depends on that piece of hardware and the software running on them both.

The other way of looking at the PS5 is that as utilisation of the CUs and the CPU increase, typically available GPU performance will reduce compared to a fixed performance unit. That's not a flaw, it's simply what's to be expected.

Sony's solution is extremely effective, but the first year or two of games, which are less likely to run into power limits (or do so to a smaller extent), will show the best performance relative to fixed clocks.

I've said this before, but Sony's solution is brilliant because early software (particularly the first couple of years) will probably benefit most relative to Xbox, and it's pretty much the first couple of years that matter most.

Four years from now, probably no-one will actually care if Ray Tracing heavy games run at a 10% higher dynamic res (or whatever) on one platform rather than another.

future games on ue5 won't have to use triangle rt at all also if Tim Sweeney talk wasn't just marketing bs ue5 seems to be quite tailored for ps5 ssd capabilities so in future games difference advantage not necesery have to be on xbox side

 

[Dictator]

future games on ue5 won't have to use triangle rt at all also if Tim Sweeney talk wasn't just marketing bs ue5 seems to be quite tailored for ps5 ssd capabilities so in future games difference advantage not necesery have to be on xbox side

Won't use triangle RT at all? huh?

 

[Rodéric]

It could be the OS and filesystem making a difference.
(People are so used to Windows they tend to forget there are "better" OS out there )

 

[goonergaz]

Won't use triangle RT at all? huh?

Yeah, even I'm confused (not hard TBH)...pretty sure RT can be used in UE5

BTW, is this Alex? Just watched the Control for PC RT video - thanks so much, really helps me understand the tech and hopefully will help me getting the best from my setup

 

[jlippo]

future games on ue5 won't have to use triangle rt at all also if Tim Sweeney talk wasn't just marketing bs ue5 seems to be quite tailored for ps5 ssd capabilities so in future games difference advantage not necesery have to be on xbox side

Just like triangle RT won't have to be used on UE4.
Doesn't mean that an ability to use hardware box and triangle intersections for something is not useful.

 

[snc]

Won't use triangle RT at all? huh?

lumen is not based on triangle rt and for many developers this approach could be sufficient

 

[snc]

Just like triangle RT won't have to be used on UE4.
Doesn't mean that an ability to use hardware box and triangle intersections for something is not useful.

I don't think ue5 will kill triangle rt ;d Maybe bad gramatic form I used, just ue5 last demo didn't show any triangle rt so it's not heavy focused on it probably

 

[jlippo]

I don't think ue5 will kill triangle rt ;d Maybe bad gramatic form I used, just ue5 at least demeonstartion didn't show any triangle rt so it's not heavy focused on it probably

For the things shown in demo it was not used, yes.

It certainly will be interesting to see what methods will be used for proper reflections and/or RT in general for nanite geometry.
Could be anything from triangle RT or custom intersections after bounding box to fully custom solution.

As engine it will most likely have a RT method or evolution of the one found in UE4, pretty sure use of nanite geometry is not forced in any way.

 

[zed]

I've often wondered how far I'd get with an all solar setup here in the Grim North of England. Probably not very. I could cover a tennis court with solar panels and after a year I'd amass enough energy to make an LED flicker a bit.

OT but contrary to what many ppl think (like I used to think before) theres not a huge difference where in the world you live. i.e. its not like if you are in the sahara you're 10-20x better off than someone in scotland.
eg southern spain is only about 70% better than north germany
Remember even when its cloudy its still generating power

 

[zed]

Ah, to dream about living in a part of the world with enough sun to make that feasible. Even on the sunny days there's still chance of overcast 10-15 minutes later. Stupid North East Ohio... https://www.bestplaces.net/climate/city/ohio/cleveland

OT: FWIW houston texas is only ~15% better than cleveland ohio.

 

[Deleted member 11852]

I haven't ruled that out, no, but hitching typically isn't correlated with a system that is struggling with workload demands.

Can you explain this because I don't understand how one type of problem is typically attributed to either software or hardware. Games move bits around, to do this the bits go through the game software, the APIs and the hardware and any one, or combination or two or more, can result in insufficient numbers of bits moving in the time desired.

This looks really like something you could attribute to thin/fast vs wide/slow architecture differences. In hardware design, given the same amount of cache thin parallel designs are more cache friendly than wide designs for the simple reason that the more things you are doing in parallel, the greater the scope for one of more execution units needing data outside of the cache.

E.g. if your cache is 32kb wide and you have 16 executions units using 31kb of that data it's fine as it's all in cache. If you have 20 executions units, with sixteen processes using 31kb of that 32kb you better hope that whatever the other four execution units are doing, they can fit that data in the remaining 1kb spare cache otherwise you're trying to work on too much data and falling back to a slower level of cache or RAM. This is why on highly parallel servers, you not only have much more L1, L2 and L3 cache you also have L4 cache.

Maybe XSX has more cache to compensate ¯\_(ツ)_/¯

 

[function]

This looks really like something you could attribute to thin/fast vs wide/slow architecture differences. In hardware design, given the same amount of cache thin parallel designs are more cache friendly than wide designs for the simple reason that the more things you are doing in parallel, the greater the scope for one of more execution units needing data outside of the cache.

E.g. if your cache is 32kb wide and you have 16 executions units using 31kb of that data it's fine as it's all in cache. If you have 20 executions units, with sixteen processes using 31kb of that 32kb you better hope that whatever the other four execution units are doing, they can fit that data in the remaining 1kb spare cache otherwise you're trying to work on too much data and falling back to a slower level of cache or RAM. This is why on highly parallel servers, you not only have much more L1, L2 and L3 cache you also have L4 cache.

Maybe XSX has more cache to compensate ¯\_(ツ)_/¯

XSX has more L0 (scales with CUs) and most probably more L2 GPU cache (scales with number of memory controllers), but I think what lets you rule out narrow / fast vs wide / slow as the cause of the hitching is that the XSX is taking several hundred percent longer to process those hitched frames, and they can often be tied to certain transition points or events in game. You could disable half of the XSX CUs entirely and you still shouldn't be seeing frames taking 3 times longer to complete. XSS has the same problem, despite having fewer CUs per SE.

For the hardware to be the root cause you'd need to be looking at a serious hardware bug that was causing scheduling of hardware access or of workloads to fail catastrophically. If it's that some aspect of your game pipeline has fallen behind over a large number of frames and you're playing catch up, then that's really a cumulative software side issue and not indicative of GPU performance across the period of a frame.

I've got not doubt that the PS5's narrow / fast arrangement is better at keeping the CU's busy, particularly at the moment, but going 40% wider shouldn't make the system liable to being 300% slower unless something is very broken. Occams Razor and all that, but I think this has to be software (even if that's on MS's side).

 

[Globalisateur]

XSX has more L0 (scales with CUs) and most probably more L2 GPU cache (scales with number of memory controllers), but I think what lets you rule out narrow / fast vs wide / slow as the cause of the hitching is that the XSX is taking several hundred percent longer to process those hitched frames, and they can often be tied to certain transition points or events in game. You could disable half of the XSX CUs entirely and you still shouldn't be seeing frames taking 3 times longer to complete. XSS has the same problem, despite having fewer CUs per SE.

For the hardware to be the root cause you'd need to be looking at a serious hardware bug that was causing scheduling of hardware access or of workloads to fail catastrophically. If it's that some aspect of your game pipeline has fallen behind over a large number of frames and you're playing catch up, then that's really a cumulative software side issue and not indicative of GPU performance across the period of a frame.

I've got not doubt that the PS5's narrow / fast arrangement is better at keeping the CU's busy, particularly at the moment, but going 40% wider shouldn't make the system liable to being 300% slower unless something is very broken. Occams Razor and all that, but I think this has to be software (even if that's on MS's side).

XSX has more L2 cache, but comparatively less than PS5. XSX has 44% more CUs than PS5, but only 25% more L2 cache.

 

[iroboto]

Can you explain this because I don't understand how one type of problem is typically attributed to either software or hardware. Games move bits around, to do this the bits go through the game software, the APIs and the hardware and any one, or combination or two or more, can result in insufficient numbers of bits moving in the time desired.

This looks really like something you could attribute to thin/fast vs wide/slow architecture differences. In hardware design, given the same amount of cache thin parallel designs are more cache friendly than wide designs for the simple reason that the more things you are doing in parallel, the greater the scope for one of more execution units needing data outside of the cache.

E.g. if your cache is 32kb wide and you have 16 executions units using 31kb of that data it's fine as it's all in cache. If you have 20 executions units, with sixteen processes using 31kb of that 32kb you better hope that whatever the other four execution units are doing, they can fit that data in the remaining 1kb spare cache otherwise you're trying to work on too much data and falling back to a slower level of cache or RAM. This is why on highly parallel servers, you not only have much more L1, L2 and L3 cache you also have L4 cache.

Maybe XSX has more cache to compensate ¯\_(ツ)_/¯

If you are referring to stuttering, then yes, there is some sort of synchronization issue between the GPU and CPU that the frame times are uneven causing a stutter, this is a GPU issue. If you are getting a reproducible hitch that occurs before text or a level is loading, that is unlikely to be the same issue as a stutter which will occur everywhere and anywhere.

Hope that helps at least on how I define the difference between the two.

ie; if you turn on VRR or Gsync and you cannot remove the stuttering it’s not a GPU frame time issue, as the monitor and uneven frame times are synced. The issue lies elsewhere for there to be a stall. I would refer to this as a hitch.

 

[function]

XSX has more L2 cache, but comparatively less than PS5. XSX has 44% more CUs than PS5, but only 25% more L2 cache.

Indeed, and depending on cache access patterns that could cause efficiency to drop on XSX relative to PS5. But it's not going to cause the game to stop on XSX for several frames.

And Control can stop at these odd points - it's not just a case of dropping frames (like when you're overloaded by Alpha or miss frame time budget). CPU side game world simulation, everything, kinda halts (very briefly!). That's not normal GPU performance stuff.

 

[snc]

XSX has more L0 (scales with CUs) and most probably more L2 GPU cache (scales with number of memory controllers), but I think what lets you rule out narrow / fast vs wide / slow as the cause of the hitching is that the XSX is taking several hundred percent longer to process those hitched frames, and they can often be tied to certain transition points or events in game. You could disable half of the XSX CUs entirely and you still shouldn't be seeing frames taking 3 times longer to complete. XSS has the same problem, despite having fewer CUs per SE.

For the hardware to be the root cause you'd need to be looking at a serious hardware bug that was causing scheduling of hardware access or of workloads to fail catastrophically. If it's that some aspect of your game pipeline has fallen behind over a large number of frames and you're playing catch up, then that's really a cumulative software side issue and not indicative of GPU performance across the period of a frame.

I've got not doubt that the PS5's narrow / fast arrangement is better at keeping the CU's busy, particularly at the moment, but going 40% wider shouldn't make the system liable to being 300% slower unless something is very broken. Occams Razor and all that, but I think this has to be software (even if that's on MS's side).

how is this frame take 3x longer calculated ? just curious (what scene example)

 

[Deleted member 11852]

If you are referring to stuttering, then yes, there is some sort of synchronization issue between the GPU and CPU that the frame times are uneven causing a stutter, this is a GPU issue. If you are getting a reproducible hitch that occurs before text or a level is loading, that is unlikely to be the same issue as a stutter which will occur everywhere and anywhere.

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. ¯\_(ツ)_/¯