Next Generation Hardware Speculation with a Technical Spin [post E3 2019, pre GDC 2020] [XBSX, PS5]

Status
Not open for further replies.
I think people are confusing the USB type A rectangular connector with the slower USB 2.0 interface? It still can be USB 3.0 & 3.1 Super Speed interface with the standard USB-A connector. Look at current desktop gaming PCs, they still all have a mix of USB 2.0(type A, USB 3.0/3/1(type A) & USB 3.1/3.2(type C) ports on the front & back. If you go dual lane USB 3.2 is where you need the type C connector.

Tommy McClain
 

Was this ever posted? Best measurement of Xsx die size. 407mm2.
17.5mm² in height...just enough to add one more WGP row. I am now pretty sure they will have 2 shader engines and 15WGPs on each side equaling 60CUs with 1 deactivated on each side. 3 x 5 in a row on each side. 23mm² is 5.5mm² extra in length over Navi 10, which means ~ 100mm² of die space extra.

Otherwise that height does not make sense. Navi 10 is 14.2mm² with 4WGPs + PHYs. That would put height of each WGP around ~2.5mm² which does not fit 17.5mm² but it does when RT hardware is counted in.
 
17.5mm² in height...just enough to add one more WGP row. I am now pretty sure they will have 2 shader engines and 15WGPs on each side equaling 60CUs with 1 deactivated on each side. 3 x 5 in a row.

Otherwise that height does not make sense. Navi 10 is 14.2mm² with 4WGPs + PHYs. That would put height of each WGP around ~2.7mm².

Yep. GitHub leaks already confirmed two shader engines.

Btw do the PS5 OQA die size still stand up to scruntiny?
 
Yep. GitHub leaks already confirmed two shader engines.

Btw do the PS5 OQA die size still stand up to scruntiny?
IMO yes, perfectly actually. I think Scarlett is slightly smaller then 407mm² as well. But it has 16mm² extra for 320bit bus + 20CUs more - 45mm² without RT. If we assume RT is 10% increase in CU size, itS extra ~15mm² for Scarlett and 10mm² for Oberon.

Oberon if 40CU chip

251mm² + 10mm²RT + ~50mm² Zen2 + 3D audio = 310-320mm²

Arden if 60CU chip

251mm² + 45mm² (20CU) + 15mm²RT + 16mm² (64bit additional PHY) + 50mm² Zen2 + any extra HW = 380-390mm²
 
IMO yes, perfectly actually. I think Scarlett is slightly smaller then 407mm² as well. But it has 16mm² extra for 320bit bus + 20CUs more - 45mm² without RT. If we assume RT is 10% increase in CU size, itS extra ~15mm² for Scarlett and 10mm² for Oberon.

Oberon if 40CU chip

251mm² + 10mm²RT + ~50mm² Zen2 + 3D audio = 310-320mm²

Arden if 60CU chip

251mm² + 45mm² (20CU) + 15mm²RT + 16mm² (64bit additional PHY) + 50mm² Zen2 + any extra HW = 380-390mm²

Are we entirely sure that the 3D audio isn't a seperate die?.
 
IMO yes, perfectly actually. I think Scarlett is slightly smaller then 407mm² as well. But it has 16mm² extra for 320bit bus + 20CUs more - 45mm² without RT. If we assume RT is 10% increase in CU size, itS extra ~15mm² for Scarlett and 10mm² for Oberon.

Oberon if 40CU chip

251mm² + 10mm²RT + ~50mm² Zen2 + 3D audio = 310-320mm²

Arden if 60CU chip

251mm² + 45mm² (20CU) + 15mm²RT + 16mm² (64bit additional PHY) + 50mm² Zen2 + any extra HW = 380-390mm²

Yeah I've done these measurements too. I was thinking more along the lines of die width compared to Navi 10.
 
IMO yes, perfectly actually. I think Scarlett is slightly smaller then 407mm² as well. But it has 16mm² extra for 320bit bus + 20CUs more - 45mm² without RT. If we assume RT is 10% increase in CU size, itS extra ~15mm² for Scarlett and 10mm² for Oberon.

Oberon if 40CU chip

251mm² + 10mm²RT + ~50mm² Zen2 + 3D audio = 310-320mm²

Arden if 60CU chip

251mm² + 45mm² (20CU) + 15mm²RT + 16mm² (64bit additional PHY) + 50mm² Zen2 + any extra HW = 380-390mm²
You need to account for almost everything on the I/O die outside of the memory interface. That means PCIe and lower speed I/O.
 
You need to account for almost everything on the I/O die outside of the memory interface. That means PCIe and lower speed I/O.

For the "voluntary" EU guidelines they need to get standby power very low. They also probably want to be able to download things during standby. I think the best way to achieve this would be to have a second chip "south bridge", that is attached to the flash and all low-speed IO, a low-power cpu and a little bit of it's own ram, and which is connected to the main APU with a 4x pci-e 4.0 link or a lower-powered equivalent. Then the main APU IO would literally be just the GDDR 6 bus and that link to the south bridge, and nothing else.

Additional bonus would be that all the low-speed IO would be on a chip with a cheaper and more suitable process.
 

Was this ever posted? Best measurement of Xsx die size. 407mm2.
Very high margin of error, the corner smds will have the most distortion and the left string of smds have a different spacing than the right one, so it may or may not be the exact same distance between the two parts. There is also no guarantee the space between these two parts is the same on scorpio and scarlet. Or that the underlying BGA pitch is the same.

He should use pairs everywhere on the board and see if there's a discrepancy or not. Including comparing a horizontal with a vertical one.

So far I remain convinced it's 380 mm2, which should be enough for 60CU with a few disabled?
 
Last edited:
Very high margin of error, the corner smds will have the most distortion and the left string of smds have a different spacing than the right one, so it may or may not be the exact same distance between the two parts. There is also no guarantee the space between these two parts is the same on scorpio and scarlet. Or that the underlying BGA pitch is the same.

He should use pairs everywhere on the board and see if there's a discrepancy or not. Including comparing a horizontal with a vertical one.

So far I remain convinced it's 380 mm2, which should be enough for 60CU with a few disabled?
I am thinking 380ish as well. 400+mm² is too much for 60CUs (and we know they want to make it as tight as possible).
 
Why should it be 60 CUs ? Where does it come from ? Who invented that ? Github leak states the number of shaders (totaling 56CUs) which is different than the specified number of WGP (clearling meaning activated) for different tests for Ariel.

How would they arrange an odd number of WGP on each sides considering how it's arranged on 5700XT ? Wouldn't that odd number be a problem somehow ?

Everything points to 56CUs being the total number of CUs because it's how MS did it on XBX devkit (all CUs activated) and we should expect the same for Arden, which is most likely the devkit. We have no reason to expect differently.

A 56CUs design would be quite easy: by adding 4 WGPs on each sides of the 5700XT design. Why would they bother with an odd and complicated 60CUs design ? Even with GCN they never done such a thing AFAIK.
 
Why should it be 60 CUs ? Where does it come from ? Who invented that ? Github leak states the number of shaders (totaling 56CUs) which is different than the specified number of WGP (clearling meaning activated) for different tests for Ariel.

How would they arrange an odd number of WGP on each sides considering how it's arranged on 5700XT ? Wouldn't that odd number be a problem somehow ?

Everything points to 56CUs being the total number of CUs because it's how MS did it on XBX devkit (all CUs activated) and we should expect the same for Arden, which is most likely the devkit. We have no reason to expect differently.

A 56CUs design would be quite easy: by adding 4 WGPs on each sides of the 5700XT design. Why would they bother with an odd and complicated 60CUs design ? Even with GCN they never done such a thing AFAIK.
Most assume the design will allow 4CUs to be disabled to boost overall yield.
 
Why should it be 60 CUs ? Where does it come from ? Who invented that ? Github leak states the number of shaders (totaling 56CUs) which is different than the specified number of WGP (clearling meaning activated) for different tests for Ariel.

How would they arrange an odd number of WGP on each sides considering how it's arranged on 5700XT ? Wouldn't that odd number be a problem somehow ?

Everything points to 56CUs being the total number of CUs because it's how MS did it on XBX devkit (all CUs activated) and we should expect the same for Arden, which is most likely the devkit. We have no reason to expect differently.

A 56CUs design would be quite easy: by adding 4 WGPs on each sides of the 5700XT design. Why would they bother with an odd and complicated 60CUs design ? Even with GCN they never done such a thing AFAIK.

Arden devkit SOC matches retail Xsx according to Hmgqq. This comment was verified y Era mods.

Either the devkit has disabled CUs out of 60, or retail has all 56 enabled.

I thinking the latter makes sense. Defective chips with defective Zen 2 cores / CUs gets used in Azure, where there is a much greater range of performance SKUs targeted, compared to the 2 SKUs in the retail consoles.
 
Why should it be 60 CUs ? Where does it come from ? Who invented that ? Github leak states the number of shaders (totaling 56CUs) which is different than the specified number of WGP (clearling meaning activated) for different tests for Ariel.

How would they arrange an odd number of WGP on each sides considering how it's arranged on 5700XT ? Wouldn't that odd number be a problem somehow ?

Everything points to 56CUs being the total number of CUs because it's how MS did it on XBX devkit (all CUs activated) and we should expect the same for Arden, which is most likely the devkit. We have no reason to expect differently.

And 56CUs design would be quite easy: by adding 4 WGPs on each sides of the 5700XT design.
Only reason we take 56CU as "gospel" is because other chip theoretical CU number is specifically active.

But on different note, how do you see 56CU chip on 320bit bus? And on top of that, it has to fit height and length of Scarlett chip we saw.

Arden devkit SOC matches retail Xsx according to Hmgqq. This comment was verified y Era mods.

Either the devkit has disabled CUs out of 60, or retail has all 56 enabled.

I thinking the latter makes sense. Defective chips with defective Zen 2 cores / CUs gets used in Azure, where there is a much greater range of performance SKUs targeted, compared to the 2 SKUs in the retail consoles.
No, Era mods verified he COULD have info (around GDC), that is - he could be someone with access to the info. As with Klee, his info is not verified and honestly I suspect he is full of shit. Especially after him and Klee pretty much confirmed 64CUs.
 
Last edited:
Arden devkit SOC matches retail Xsx according to Hmgqq.

Either the devkit has disabled CUs out of 60, or retail has all 56 enabled.

I thinking the latter makes sense. Defective chips with defective cores / CUs gets used in Azure, where there is a much greater range of performance SKUs targeted, compared to the 2 in the retail consoles.
What does he mean by 'matches' ? because he actually doesn't know if the tflops specs matche like the way it's done on XBX.


I think he must be talking about the fact that both APUs are identical (in features) and the clocks.

We really should speculate using a recent big APU design done by the same team IMO, the way it's done on XBX. And even if this insider knows the final specs he doesn't seem to know much about the actual specifics of both clocks and CUs.

Is it 56CUs at 1700mhz ?
Sounds about right.
Does the devkit has more tf like on XBX ?
Maybe, but the SoC chip matches nevertheless.

Sounds ? Maybe ? That's pretty vague.

One thing he seems to actually know for a fact is that it's not using RDNA2: :LOL:

It's RDNA2 ?
That's a definitive statement.

Most assume the design will allow 4CUs to be disabled to boost overall yield.
Well then 56CUs for the devkit and 52CUs for the retail machine.
 
Last edited:
Status
Not open for further replies.
Back
Top