Mark Cerny said:
In my opinion, I think Cerny's quote is speficially about standard 3D queue for rendering. Compute shaders are very efficient at leveraging all the hardware resources to do work, saturation should be very good. In this case, UE5 should be very taxing on all GPUs.
And ? He gave an example about the whole GPU power consumption (his Pro heating up so much) stating it was a practical test for this claim. Remember that he is talking about the number of polygons here, not quality of lighting / textures.
Board power consumed is based on the number of transistors flipping bits, in this case, the typical standard 3d pipeline uses the CUs as their workspace, but they are required to follow along a specific path and are still limited to the restrictions of each shader type despite the CUs serving as unified shader hardware. Typically speaking, the most complex the graphics are, or even geometry, the more likely you'll hit both saturation and stalling issues on the standard 3D graphics queue. You don't run into these issues with Compute shaders as much, they are able to take full advantage of all the available CUs and schedule the work in to be done, combined with Async compute, you can get very thorough workout on your CUs. If you're getting a lot of action there on the CU side of things (which represent the largest part of the GPU in terms of die size) and you're not leveraging the fixed function hardware as much (the ROPs and primitive generation/discard which represnt a small amount of die space) then you're likely to use a lot more power.
Due to stalling what, the CUs? So in low-geometry scenes you're stalling the geometry stages. Meaning you're not "stalling more", you're just "stalling somewhere else".
The CUs may not be the big silicon consumer of the PS5's SoC. I mean it should still constitute "the largest area in the die consisted of similar units", but it's at least not as big in proportion as it was with the PS4 Pro or maybe even the PS4. We're now looking at probably 40 CUs total which isn't that wide, there's a block with "a large EDRAM pool" dedicated to I/O and they changed from the paltry Jaguar to much larger Zen2 cores.
Yes.
With low geometry, you're just completing the geometry stage faster and moving on to the CUs. Whether the CPU / GPU-front end feeds the geometry stages after that will be up to how the renderer is architected, I think. Compute Units make up the majority of the die, so it's natural to expect that power consumption would increase if it's not stalling on the geometry. With the clock vs power relation, you'd expect that even moreso.
But he mentioned very specifically Horizon's map that had very low geometry, pushing a lot of power.
Do all games with menus or maps ramp up the power consumption?
Mark Cerny said:
no one here is refuting that. And Al is agreeing with you as to why that could be the case. But using UE5 as an example is not apple to apples comparison here. UE5 does it's geometry generation and discard through compute shaders and not through the fixed function pipeline that _all_ other games do; Cerny's musings on power performance with respect to geometry density do not apply in that case.
We've been here before, transistors are not all equal.
Please report to the Re-conditioning team for "re-education" 
It doesn't matter if transistors are optimized for their role or not, power usage is still based on transistor flipping bits. Just because you've got different transistors doesn't mean flipping bits will suddenly be free.We've been here before, transistors are not all equal.
No change is free, but when a change is 800% more power efficient than another, then you can't use transistor states changes as a metric.
