More that the Gen 2 mode is the bare minimum of performance that devs can expect from the PS5, meaning dev kits can be put in the hands of developers a good 12-18 months before release. Meanwhile, Sony has a chip which they can use to test BC.
I do not believe you would build an entirely separate chip for the sake of testing BC. The chip that needs to work with BC is the PS5 one. It’s don’t believe you can test one chip and port over the design to another chip that is inflight with its own customizations. That’s sounds incredibly inefficient and difficult to do.
No context was ever given for the leaks.
We live in the world of super-secrecy in hardware development where information is often highly fragmented among teams.
If this particular team was simply testing all the BC modes, there wouldn't need to be telling the team exactly how many CUs there are in the hardware itself.
Since the team working on BC modes only needs to know that BC uses up to 36CU, there's no reason to tell them exactly how many CU there are in the chip.
Effectiveness isn't a problem; it's whether it can run without issues or not.
Running without issues is well within the
definition of effective. If there are issues, then it doesn't produce the desired effet.
Effectiveness is the problem.
Also, do games have that level of CU allocation control?
Others already answered better than I could ever do. Regardless, the answer is yes.
PS4P went the safest possible route, using the same architecture.
Rather a superset of the existing architecture, as Neo introduces native FP16, 2xFP16 throughput plus IIRC a bunch of features focused on VR.
But's a superset of the previous architecture with 100% hardware compatibility yes.
One thing I dont get is people saying "36CUs is not enough, its same amount as Pro".
No. RDNA CUs are very big, considerably bigger then GCN. 40CU in Navi is likely more akin to ~60CU GCN in space on same node.
Radeon 7 is 13B transistor 330mm² chip with HBM memory interface. Navi 10 on 256bit bus is 251mm² and 10.3B transistors.
1 -
GDDR6 dual-32bit PHYs are 50-75% larger than HBM2 ones. Navi 10 is already losing die area to Radeon 7 / Vega 20 there.
2 - ROP count is the same in Navi 10 and Vega 20, so that isn't counting for the scale comparison between one and the other, and neither are the I/Os (both use x16 PCIe 4.0 BTW).
3 - IIRC Vega 10 NCUs were ~4mm^2. I never saw the area for the same CUs in the 7nm Vega 20 (which wouldn't be a fair comparison because those are 1:2 FP64 throughput capable), but assuming AMD's own 2x density improvements then 2x Vega NCUs @ 7nm are 4mm^2. One WGP is estimated to be
4.5mm^2.
There's no reason to believe the RDNA CUs are "considerably bigger" than 7nm NCUs, unless you have a source stating otherwise.
So no, 40CU GPU Navi chip in console is not small, especially since its going to have additional hardware reserved for RT. It cannot be compared to Pro in any way.
It's not expected to be small. I expect it to be around 350mm^2.
For backwards compatibility on a different microarchitecture, I'm actually curious as to whether having an exact match in counts and clocks would be sufficient. CU count might require a match for other reasons, but unless the hardware is painstakingly matching the cycle behavior of the original hardware, I'd expect that additional clock speed at each BC level would be needed to help get over any areas where hardware doesn't fully match.
Navi does drop a number of instructions, which if any were used would need additional hardware put back into Navi or some kind of trap and emulate method that would cost clock cycles. One potential area that well-optimized GCN vector code could hit is a stream of dependent vector instructions that managed to hit high utilization on Southern Islands. In its first generation, RDNA is 25% longer-latency for dependent instructions, which is one place where bumping the clock would be a ready option for compensating.
Desktop RDNA on Navi 10 may drop instructions from previous GCN, but PS5's RDNAx definitely does not.
Otherwise the 9 WGP @ 800MHz and 18 WGP @ 911MHz tests wouldn't make any sense.
Unless you're assuming the github leak might be false.