Current Generation Hardware Speculation with a Technical Spin [post GDC 2020] [XBSX, PS5]

[boipucci]

Plenty of speculation that's mostly around the SOC being too small to have significant portions of IC, when you build up what area is used.

Thought the same up until a few minutes ago when i saw 6900xt die size and halved it (260mm2). 64mb ic doesn't seem so crazy anymore
260mm2 for GPU and IO 48mm2 for CPU and TE. I estimate zen2 block around 40mm2 based on renoir die (156mm2 total)

Granted it's a tight fit but it seems plausible, the only thing that makes me doubt is why Sony haven't bragged about it? perhaps Cerny couldn't mention before amd reveal rdna2

 

[Deleted member 11852]

I agree. But it's not marked. We have no real way of knowing how much effort was placed to the port.
All my game icons on my screen, any title that has been patched to take advantage of some features of X|S will have the X|S icon on them.
There is no way for a player to actually know how much has actually been done just because the badge is there.

I solved this back in June but Microsoft decided not ti implement it. To be fair, I didn't specifically market it to Microsoft but it's their fault if they don't read all my posts.

 

[Globalisateur]

Thought the same up until a few minutes ago when i saw 6900xt die size and halved it (260mm2). 64mb ic doesn't seem so crazy anymore
260mm2 for GPU and IO 48mm2 for CPU and TE. I estimate zen2 block around 40mm2 based on renoir die (156mm2 total)

Granted it's a tight fit but it seems plausible, the only thing that makes me doubt is why Sony haven't bragged about it? perhaps Cerny couldn't mention before amd reveal rdna2

On XSX APU I estimated the CPU (8 Zen 2 cores + 8MB L3 cache) use about 41 mm².

 

[BRiT]

Thought the same up until a few minutes ago when i saw 6900xt die size and halved it (260mm2). 64mb ic doesn't seem so crazy anymore
260mm2 for GPU and IO 48mm2 for CPU and TE. I estimate zen2 block around 40mm2 based on renoir die (156mm2 total)

Granted it's a tight fit but it seems plausible, the only thing that makes me doubt is why Sony haven't bragged about it? perhaps Cerny couldn't mention before amd reveal rdna2

There's also addition transitors for their customizations and other enhancements like that audio driven CU Tempest. Is their Kraken Decompression a separate chip?

 

[j^aws]

Thought the same up until a few minutes ago when i saw 6900xt die size and halved it (260mm2). 64mb ic doesn't seem so crazy anymore
260mm2 for GPU and IO 48mm2 for CPU and TE. I estimate zen2 block around 40mm2 based on renoir die (156mm2 total)

Granted it's a tight fit but it seems plausible, the only thing that makes me doubt is why Sony haven't bragged about it? perhaps Cerny couldn't mention before amd reveal rdna2

Doesn't work by halving Navi21s die; you are not accounting for PS5s APU with these:

- need to add back 4 memory controllers as 8 is still required for 256bit bus
- need to add back 4 PHYs as bus is still 256bits wide
- need to add Tempest Engine, around 1 CU
- need to add IO Complex logic
- need to add SRAM in IO Complex, undisclosed amount
- need to account for any difference in on-die multimedia logic (could be off-die)
- need to account for any difference in Southbridge IO logic

That's a lot to account for. The IO Complex SRAM hierarchy could be considered a form of 'Infinity Cache' (marketing term). This SRAM could be anywhere from 512KB to 8MB maximum from my estimations.

 

[Rurouni]

There's also addition transitors for their customizations and other enhancements like that audio driven CU Tempest. Is their Kraken Decompression a separate chip?

It is part of their I/O complex, which is basically integrated into the APU.

 

[PSman1700]

Yes IC seems kinda off the cards. I also think we would have known about it by now.

 

[boipucci]

There's also addition transitors for their customizations and other enhancements like that audio driven CU Tempest. Is their Kraken Decompression a separate chip?

Decompression unit is part of IO block, TE is based around a CU without caches so ~3mm2

- need to add back 4 memory controllers as 8 is still required for 256bit bus
- need to add back 4 PHYs as bus is still 256bits wide

Good points i missed that, however i think memory controllers or PHYs are the same or accounted within
Still we are missing four 32bit memory controllers ~30mm2 that definitely eats a chunk of the remaining space

- need to add Tempest Engine, around 1 CU

~3mm2

- need to add IO Complex logic

I think that's accounted, 5700 io was ~37mm2 and xsx ~18mm2. Even if we halve 5700 die we are still left with enough for the xsx die ~18mm2.

Question: Would IO of the 6900xt be same size or bigger than 5700s?

- need to add SRAM in IO Complex, undisclosed amount

Whats the minimum size area wise for arguments sake?
Before going forward let me make it clear im not trying to prove infinity cache is a done deal, im merely trying to speculate whether it's possible within ~308mm2 die size

So far we have 260mm2 + 30mm2 (4phy) + 3mm2(TE) + 40mm2 (Zen2) = 333mm2 (25 in excess of 308)
Now would reducing IC from 64 to 54MB cache free the excess space? and is there any PC GPU focused logic Sony can get rid off to free space?

 

[Deleted member 91098]

I haven't kept up with all the talk about RDNA after the AMD 6800 launch, so I don't know if this is common knowledge already, but apparently RDNA 1.1 [0] exists and is very similiar to RDNA 2. The author assumes it's what's used in the consoles which would be interesting remembering all that RDNA 1.5 talk around the net even after RDNA 2 being mentioned at the console reveals.




[0] https://www.hardwaretimes.com/amd-r...rchitectural-deep-dive-a-focus-on-efficiency/

 

[liams]

I haven't kept up with all the talk about RDNA after the AMD 6800 launch, so I don't know if this is common knowledge already, but apparently RDNA 1.1 [0] exists and is very similiar to RDNA 2. The author assumes it's what's used in the consoles which would be interesting remembering all that RDNA 1.5 talk around the net even after RDNA 2 being mentioned at the console reveals.

If they, just to go with the authors idea, both used RDNA 1.1, I wonder what Microsoft waited for? it must have been something they considered substantial. Maybe VRS / mesh shading support? I know thats supposed to be the killer app of DX12U. And looking at it the timelines match up, Digital Foundry and Austin Evans went up to microsoft at the end of march, and DX12U was unveiled at the beginning of march. Maybe they were waiting to see if the VRS hardware would be done in time for them to freeze the silicon design and start making chips/consoles?

So I think they were waiting until the silicon was finalised to decide what the features of DX12U actually were going to be, if VRS hardware support was going to come too late for the console it wouldn't be in DX12U, or at least not promoted as the next big thing.

 

[iroboto]

If they, just to go with the authors idea, both used RDNA 1.1, I wonder what Microsoft waited for? it must have been something they considered substantial. Maybe VRS / mesh shading support? I know thats supposed to be the killer app of DX12U. And looking at it the timelines match up, Digital Foundry and Austin Evans went up to microsoft at the end of march, and DX12U was unveiled at the beginning of march. Maybe they were waiting to see if the VRS hardware would be done in time for them to freeze the silicon design and start making chips/consoles?

So I think they were waiting until the silicon was finalised to decide what the features of DX12U actually were going to be, if VRS hardware support was going to come too late for the console it wouldn't be in DX12U, or at least not promoted as the next big thing.

Off the top of my head:
VRS
Mesh Shaders
SFS

 

[iroboto]

The June 2020 devkit as noted in the Leaked Devkit Release notes, did have previous versions. And with all the issues cropping up now in the gameplay shown by DF and others with the XBSX performing underpar, I doubt the June 2020 version will be the last or final update and it will likely have many more iterations to fix all the issues cropping up.

With DF and others getting access to the hardware in March 2020, I would expect that the specs would have been finalised at that point. I mean the XBSX was announced in Dec 2019 at the Game Awards and the announced release date was Holiday 2020 and around the same time Spencer said he had one at home and was playing games on it. As far as I know, Holiday 2020 does not include August 2020. Or am I mistaken?

I would be shocked that a company like MS wouldn't have remote access and debugging tools available to developers well before Covid was ever announced. If they really had to revise their tools because of Covid, I would blame leadership for being well behind the times. Cloud storage and computing has been around for a while already and is a huge Microsoft income source.

So all devkits prior to Nov 2019 were all XDK.

The first GDK didn't arrive until Nov 2019. GDK was essentially developed through COVID, they seem to have a monthly cadence, some months missed here and there. Hopefully with each month they have more features or resolved some of the issues written about in June. June will assuredly be far from the last GDK; it's so bad lol

 

[liams]

The first GDK didn't arrive until Nov 2019. GDK was essentially developed through COVID, they seem to have a monthly cadence, some months missed here and there. Hopefully with each month they have more features or resolved some of the issues written about in June. June will assuredly be far from the last GDK; it's so bad lol

Well heres to hoping that it pays off for them in the end. Seems like they want the GDK to be the UWP of gaming.

I dont know if you would know, but when did the decision to go all in on GDK happen? seems weird to have the first preview version of GDK a year from release of your new console, I would have thought you would have wanted that in devs hands much earlier than that.

It would be interesting to learn whats on their bug fixing short list, and how much a lot of these performance issues are being caused by just a couple of things, or if the whole of the GDK is a mess right now.

One thing I have thought is during the hotchips presentation they said that they write the firmware in house, maybe thats something that is causing a lot of problems? having the same size team doing two separate firmwares for the S and X, even if they are largely related, has to be a substantial increase in workload.

 

[boipucci]

I haven't kept up with all the talk about RDNA after the AMD 6800 launch, so I don't know if this is common knowledge already, but apparently RDNA 1.1 [0] exists and is very similiar to RDNA 2. The author assumes it's what's used in the consoles which would be interesting remembering all that RDNA 1.5 talk around the net even after RDNA 2 being mentioned at the console reveals.

View attachment 4966


[0] https://www.hardwaretimes.com/amd-r...rchitectural-deep-dive-a-focus-on-efficiency/

After reading the article it seems more like speculation

Below you can see the raw throughput of the RDNA 1, 1.1, and 2.0 CUs. Now, you’ll likely ask what’s RDNA 1.1? Well, AMD didn’t say but I reckon it’s what powers the PS5 and most likely the Xbox Series X. Regardless, there’s no difference between the two designs, and it’s the Render backend which has really undergone a makeover with RDNA 2.

RDNA 1.1 CUs have the optional lower precision int8/int4 added while RDNA2 CU has it by default (and by extension PS5).
There's two key differences however between 1.1 & 2.0 CUs. The latter has ray accelerators added and redesigned/optimized to hit higher frequencies at same power consumption (1.3x). Its worth mentioning that in the road to playstation presentation Cerny specifically mentioned RDNA2 CUs.

Now the following 2 slides caught my attention in relation to PS5

Designed ground up for frequency, power and efficiency. All three goals key to the PS5 design, i think this is as good confirmation as we gonna get of PS5 supporting VRS hw bits. I see no reason why Sony would forego RB+ when it perfectly suits their high frequency design. Time constraints don't seem likely considering RB+ is part of the basic RDNA2 design. Its not an added feature, optimized VRS is just a nice side effect.

If anything the delay MS mentioned could be related to them waiting to implement all RDNA2 API features on the dev kits that are certified to release launch games. It might just be a case of Sony not adding the API features on dev kits in time for launch games. But the hardware support is all there for future API/Devkits iterations

Seeing as how PS5 is coming in hot lacking features that hardware otherwise supports (VRR, 8K, cold storage, internal expansion) It seems plausible that Sony prioritized basic API features for launch with the missing features coming at a later date

Variable Rate Shading and Sampler Feedback are primarily an API-level feature, rather than a hardware one and as such works in a similar way across all GPU architectures.

XSX does have a unique customization hence SFS. An added hw texture filters to fall back to lower LODs until the streaming assets make it so its not obvious when there's a delay. Plain SF PS5 should be able to support with an API update if it doesn't already

Infinity cache seems to be designed to work exceptionally well with high frequency GPU design, i think this is the key to PS5 high clocks and it being neck to neck with XSX.
I think there's a high posibility of anywhere from 32 to 64MB of IC in on PS5. They likely settled on a sweet spot of performance per die space. Im thinking somewhere close to 50MB

Other circumstantial evidence which give more plausibility to this being the case:
Matt comment on DF face off

Imagine when people have more time to really optimize their code/data and hit these caches more often.

Cerny talk about bringing data closer where it needs to be
PS5 handling of alpha heavy scenes in games


Finally this is where i think XSX & PS5 diverge is with mesh shading where MS went for the standard RDNA2 which is simpler/easier to implement across DX12U devices whereas Sony went for a custom tailored solution something that is harder/more complicated to implement but allows for greater control and flexibility similar to NVs solution.

 

[Deleted member 7537]

What's the chance of somebody getting a PS5 SOC and an optical microscope and give us a clear picture of what they've added there?

 

[AlNom]

What's the chance of somebody getting a PS5 SOC and an optical microscope and give us a clear picture of what they've added there?

Fritzchens Fritz is probably the best bet, but someone needs to send him a PS5 unit first. So........ someday. He seemingly recently did a decap of One X, so... you could be waiting a while unless you know someone with $499USD to throw away. From what I understand, people have also just sent him dead units to lift the chips from.

 

[j^aws]

Good points i missed that, however i think memory controllers or PHYs are the same or accounted within
Still we are missing four 32bit memory controllers ~30mm2 that definitely eats a chunk of the remaining space

MCs and PHYs are not the same. You still need to add 4 PHYs to your additional 30 sq mm.

I think that's accounted, 5700 io was ~37mm2 and xsx ~18mm2. Even if we halve 5700 die we are still left with enough for the xsx die ~18mm2.

Question: Would IO of the 6900xt be same size or bigger than 5700s?

I'm referring to the PS5s SSD IO Complex, which is the block that includes Cache Scrubbers, Coherency Engines, DMA Engines et al (not including its SRAM block in that comment). This IO Complex is not the same as the Southbridge IO in the 5700. Nor the same as the SB IO from 6900XT. You halved the Navi21 die, so you also halved the SB IO.

Your XSX IO should include both Southbridge and hardware decompression for Velocity Architecture. This should already be stripped down from the PC part of the 5700 for any redundant PC GPU logic. Looking at the PS5s IO Complex, it should have more hardware logic from the aforementioned XSX IO, so you will need to add more to your 18 sq mm.

Whats the minimum size area wise for arguments sake?
Before going forward let me make it clear im not trying to prove infinity cache is a done deal, im merely trying to speculate whether it's possible within ~308mm2 die size

Since you started with 64MB of IC, see how far off you are from PS5s APU size with that amount of SRAM.

From 308 sq mm for PS5s APU, remove a few sq mm for the external packaging. So around 305 sq mm is the target.

So far we have 260mm2 + 30mm2 (4phy) + 3mm2(TE) + 40mm2 (Zen2) = 333mm2 (25 in excess of 308)
Now would reducing IC from 64 to 54MB cache free the excess space? and is there any PC GPU focused logic Sony can get rid off to free space?

See my previous comment regarding redundant PC GPU logic for XSX.

Your 333 sq mm needs to add the following:

- 4 PHYs (you already added 30 sq mm for MCs as you assumed they are the same as PHYs)
- SSD IO Complex logic (difference from XSX VA + SB IO)
- SSD IO SRAM
- Multimedia logic (could be off-die)

Your 333 sq mm already includes 64MB IC SRAM. Whatever total you get, remove your 64MB IC, and see if you hit 305 sq mm for PS5s APU. Not much space left from my estimations.

EDIT: Looks like your 30 sq mm is enough to cover 4 PHYs and 4 MCs. I estimate around 30-31 sq mm.

 

[Globalisateur]

After reading the article it seems more like speculation

...
Infinity cache seems to be designed to work exceptionally well with high frequency GPU design, i think this is the key to PS5 high clocks and it being neck to neck with XSX.
I think there's a high posibility of anywhere from 32 to 64MB of IC in on PS5. They likely settled on a sweet spot of performance per die space. Im thinking somewhere close to 50MB

Other circumstantial evidence which give more plausibility to this being the case:
Matt comment on DF face off

Cerny talk about bringing data closer where it needs to be
PS5 handling of alpha heavy scenes in games


Finally this is where i think XSX & PS5 diverge is with mesh shading where MS went for the standard RDNA2 which is simpler/easier to implement across DX12U devices whereas Sony went for a custom tailored solution something that is harder/more complicated to implement but allows for greater control and flexibility similar to NVs solution.

I think he was talking about unified L3 cache for the CPU. PS5 has 22% higher pixel performance than XSX, that should be enough to explain the advantage with alphas heavy scenes.

 

[boipucci]

MCs and PHYs are not the same. You still need to add 4 PHYs to your additional 30 sq mm.

I'll admit this stuff goes way over my head, im going by estimates done by proelite and liabe brave both of who seem to include mc/phy in their estimates

I'm referring to the PS5s SSD IO Complex, which is the block that includes Cache Scrubbers, Coherency Engines, DMA Engines et al (not including its SRAM block in that comment). This IO Complex is not the same as the Southbridge IO in the 5700. Nor the same as the SB IO from 6900XT. You halved the Navi21 die, so you also halved the SB IO.

Yes im aware but my point was that PS5 IO would replace the GPU IO so that frees up some space
Now my question: Is the 6900xt io likely to be bigger or the same size as 5700, if its 37mm2 like 5700 that would leave us with 18mm2 after we halve it for PS5 IO

Your XSX IO should include both Southbridge and hardware decompression for Velocity Architecture. This should already be stripped down from the PC part of the 5700 for any redundant PC GPU logic. Looking at the PS5s IO Complex, it should have more hardware logic from the aforementioned XSX IO, so you will need to add more to your 18 sq mm.

Yeah seems reasonable to add an extra 2-5mm2 for coherency engine, beefier decompression block & sram?

Before going further with calculations need an estimate of navi21 io size.

I think he was talking about unified L3 cache for the CPU. PS5 has 22% higher pixel performance than XSX, that should be enough to explain the advantage with alphas heavy scenes.

Could be either way but as i said its circumstantial evidence and you got to admit it fits PS5 design like a glove would definitely explain the higher efficiency allowing to be neck to neck with XSX
It's all speculation at this point but seems plausible imo?

 

[iroboto]

I dont know if you would know, but when did the decision to go all in on GDK happen? seems weird to have the first preview version of GDK a year from release of your new console, I would have thought you would have wanted that in devs hands much earlier than that.

It would be interesting to learn whats on their bug fixing short list, and how much a lot of these performance issues are being caused by just a couple of things, or if the whole of the GDK is a mess right now.

I suppose they opted for a GDK a long time ago when they decided to unify PC with console, XCloud, next gen and current gen under a single kit.
You might say the precursor to it was the XDK which supported 3 configurations of Xbox by tapping the button.

it’s not all bugs. They list some bugs. Most of it seems around missing features and tools that developers need when they are pushing the hardware boundaries.

I don’t want to overstate what the GDK could bring; but in isolation (ie do not compare to ps5) it seems a missing but critical addition on the front end and some better tools with managing memory and there should be a relevant lift in performance at least with respect to what’s listed in the June GDK.

I couldnt tell you what’s been fixed since then. And I can’t tell you how it impacts performance. We lack data points. And I do not know what GDKs the games that are being compared with shipped with. But June is the first eligible GDK. There is usually 2-4 weeks for certification. So releasing a game in Nov, you had to certify in Oct at the latest. June to Oct is 4 months, I’m not sure how many GDKs you’ll keep upgrading to if you’re hammering out bugs and you still need to deliver for XBO and X1X using the GDK just to improve the performance on XSX.

but should the front end get it’s NGG pathway (which is listed as “coming” but we can see how much uplift it brings on the 6800 series) and their memory management resolved I would hope that should lift the performance level.
Now that they are getting their butts raked, perhaps they will give these features more priority.

but to be fair and perhaps an unsung hero for them; Xbox had been very stable. Performance is not to expectation but it’s stable.

My ps5 is all over the place. I need to hard reset all the time, rebuild the database, deal with weird stuttering and OS menu challenges. That’s just me; out there I read about all sorts of other issues players are facing with random crashing and hang ups.

so it’s not all rainbows and sunshine’s on one side and rainy on the other. They’ve both got their ups and downs it seems. But not everyone experiences crashing, and not everyone experiences 120fps gaming.