AbsoluteBeginner
Regular
Baseless Next Generation Rumors with no Technical Merits [post E3 2019, pre GDC 2020] [XBSX, PS5]
- Thread starter BRiT
- Start date
- Status
snc
Veteran
playstation pad on slides
I would say it's more probable than anonymous reddit postCompletely reasonable.
If that the case, I hope they do keep all 40 CU's and can hit 2GHz. It's a completely mental thing for me. TF > 10, good. TF < 10, bad.
In 7nm+ it will have more than 40CUs .
7nm+ already begins volume production 2 months ago. The timing is just like 16nm for PS4 slim.
AbsoluteBeginner
Regular
Lets wait and see. PCB leak was, IMO, one of the best this gen.playstation pad on slides
Not only was it far too early for reasonable leaker to make up, it was so specific it really made sense (18Gbps chips on 256bit bus). That is far above what your average fake pulls out...
Also, seems like guy leaking it was from Asia (judging by time zone) and his avatar was interestingly...PCB.
AbsoluteBeginner
Regular
I think they could actually keep 40 active CUs if they really want to. It all depends on yields.
If 316mm² chip yields great, and they can get whole lot of 40CU dies vs 360mm² one, you could see that one having to deactivate some duo to yields. Interesting prospect IMO...
What, the PCB leak is from reddit? How do we know it is credible without fake number?
snc
Veteran
We don't
AbsoluteBeginner
Regular
What leads me to think he is right is following :
1. Leak itself is VERY specific. OQA PCB stuff. Its really nothing that would mean much to 99% of audience for which fake insiders are targeting their "leaks".
2. It was EARLY. Too early for many.Who thought by summer Sony would have legit devkits packed with actual APU? Not alot, but in July/Aug we got pictures of V PS5 dev kits on developer tables. You dont think there is PC motherboard in there, right?
3. No announcement dates, launch titles, TFlops, core count and competition info. Only gave what someone at manufacturing COULD know.
4. 256bit bus and 18Gbps Samsung chips (not yet in full production). Bus is way to narrow for most people who dont understand that actual BW is result of bus width and memory speed. Finding exact memory chip production number + saying its 18Gbps gives him at least benefit of a doubt. This is because Sony could really go narrow and fast therefore having smaller chip but similar bandwidth to MS solution. Obviously, duo to bus they would not have alot of headroom as they would have gone for fastest memory chip already, but if everything turns out fine they get smaller chip and alot of BW.
4. 3rd point matches perfectly with leaked Flute benchmark, which by all accounts appears to be PS5 related
5. He was from Asian time zone, had PCB avatat and deleted his account day later.
Tbh nr 5 is just for lolz, but this leak was far to specific and far to rational. For most it doesnt make alot of sense because it tells us info with which we can get picture of console power, but no "juicy" info. Also, it is very specific in which products and codes are being used on PCB.
@AbsoluteBeginner I think 316mm² at 7nm EUV (and only 8MB of CPU L3 cache) should be enough for 52 or 56 CUs (respectively 48 or 52 activated CUs). Giving respectively 12.3 tf or 13.3 tf at 2ghz: current Oberon devkit.
AbsoluteBeginner
Regular
I agree, I just dont think it will be 7nm EUV nor do I think BW provided would be enough for 13TF GPU + RT and Zen2.
My thinking is, Sony would provide 7x increase in TF and only 3.2x increase over PS4 in BW. A bit unrealistic IMO.
I dont think 256bit bus fits with 13+TF, but does for 9-10TF.
Or maybe their RT solution is less reliant on main bandwidth, but will eat the tflops, thus rending the 576GB/s bandwidth enough for the rest of rendering + CPU ?
Hmmm... a few things to add doubt...
Samsung's 16gb die is in production for HC14 bin, and sampling for HC16 bin. If there is an HC18 speed (there isn't yet, even in sampling qty) it would probably be the next die revision, so the part code would change since it includes the die revision.
It's 32GB of gddr6. Seriously, that cost a big chunk of money.
The clamshell means 18gbps speed is impossible, so benchmarks would be showing about 16gbps or even less (considering the drop for gddr5 was 6gbps parts at 5.5gbps), however the benchmark does have a drop from perfect 18gbps, just not enough to account for the rest.
Every part there is easily found and it was posted after we got the samsung part numbers in many dramatic tech news articles including anandtech. The things that would have been a good indicator is sony part numbers, they are too difficult to fake. Like the code on the main SoC or the SB.
Last edited:
Which seems consistent with realistic leaks.
AbsoluteBeginner
Regular
Keep in mind this is dev kit leak, so 32GB does make sense.
Also, Flute does not show full 576GB/s, but ~528GB/s (is it benchmark issue or not I do not know).
Samsung big numbers actually came in January 2018, not 2019. Rambus is the one that is licencing patent to others for 18Gbps chips and it will go to mass production soon, with next gen flagship Nvidia cards being the ones using it.
The Flute benchmark has 16GB. Since when clamshell mode makes the max speed impossible ? Can you elaborate ?
In clamshell there is two chips loading the same lanes (the address/command are double loaded, not the data lanes), it reduces the signal quality so a specific speed bin is lower in clamshell than the single chip mode. The best example to show this is the ps4 that was 192GB/s using 6gbps parts in the early devkit doc leak, and when they changed to 8GB clamshell there was a revision down to 5.5gbps, even though the parts are still the 6gbps ones.
Not sure if it still applies to gddr6, but it has the same topology with double loading of addr/cmd lanes....
EDIT: wait, it shouldn't impact data rate if the data lanes are single loaded, only latency is impacted by add/cmd. I'll look this up, it was sort of the observation that clamshell gpus always downclocked from the printed speed bin.
EDIT2: It really shouldn't. So I don't know why we observed this!
Last edited:
Yep I also thought clamshell meant ~8% bandwidth loss, but I couldn't find any technical reasons to back that up.
Btw,
528/576 = 91.7%
176/192 = 91.7%
coincidence?
I just read some micron's application notes for gddr5 confirming it's not supposed to have any drop in clamshell.
We jumped to conclusion for YEARS about this without ever looking it up. Hahaha!!!
The clamshell configuration was well designed to avoid having more loading on any high speed lane (data), and make it transparent on the controller side. All I can think of right now is that it might just be more difficult to design the motherboard to meet ideal speeds in clamshell. Or there's an issue with potential mismatch between the chips, or maybe the double loading on the clocks. I don't know.
- Status
Similar threads
- Locked
