Playstation 5 [PS5] [Release November 12 2020]

We'll have a good idea if it's not running at 2.23 most of the time, it will consistently render 30% less pixels per seconds on third party games.

And we'll know it's at 2.23 all the time if third parties are showing about 15% less pixels per seconds.


Assuming the PS5 will be running the exact same quality settings as Series X, which may not be the case.
If both consoles have the same amount of geometry processors then the PS5 can have e.g. less detailed shaders but higher polygon count. Lower ray count but larger streamed textures.
End result could be just different, and not an apples-to-apples comparison where you just get the same game but at a lower framerate or resolution.


Other improvements and bottlenecks will rear their ugly heads though, memory bottleneck might be dominant?
Probably, yes.
Unless we're still missing some details (like e.g. the presence of an extra 4GB DDR4 to lower the GDDR6 requests from the CPU cores), Sony really could have used 16 or even 18Gbps chips here. Assuming the memory controller's power consumption wouldn't go crazy.
 
Exactly, this time its even easier because you can just a m2 slot.

Just buy one of these and a m2 adapter and have some fun.

https://github.com/ufrisk/pcileech

There does seem to be a restriction if the OS uses an IOMMU and enables virtualization-based security. It's possible the PS5 will, given the collection of other IO processors and DMA engines running freely in the SOC.
Whether Sony implements some other form of security measures around the PCIe subsystem, or the system software has other safeguards is probably something Sony wouldn't discuss. Sony has displayed surprising amounts of neglect in its security schemes before, however.

The m2 slot's PCIe link goes to the IO block on the main SOC, same as the custom SSD does.
We know that decompression and priority arbitration would be handled in that complex, and while I don't recall a mention of decryption, I think the most likely place for encryption and tamper checking is on the main SOC. That should give some defense of the data in persistent storage, barring security flaws or Sony's already mentioned neglect.

I'm not clear where the Tempest block is, or where its DMA might be.

Left unsaid is where the OS and firmware are being loaded from or into. I'd like to think Sony learned something from how stringing the boot process over the link from a separate southbridge compromised security.
We'd need to find out whether there's still a southbridge chip, since at least one of its functions was serving as a controller for the HDD, which the PS5 would have on-die.
 
Probably, yes.
Unless we're still missing some details (like e.g. the presence of an extra 4GB DDR4 to lower the GDDR6 requests from the CPU cores), Sony really could have used 16 or even 18Gbps chips here. Assuming the memory controller's power consumption wouldn't go crazy.
I tried to explain something about this when the crazy 18gbps rumors were flying... The production of gddr6 would have a lot of volume available for the lowest clocks, and gpu card producers would pay a lot for the highest bins. Someone have to buy the bulk of the mid to low bins. That creates the same opportunity for a low cost and unfluctuating volume as the ps4 "surprisingly low" BOM. I think that's how we missed the cost prediction of ps4 8GB gddr5. But this time I thought maybe 16gbps might be the new low bin because of a new node, and it obviously didn't happen timely.

We also have a big rise in memory cost across the board, which could have caused a few late changes (pure speculation)...
1. MS went with a weird unbalanced bus for their ram to keep ram cost under control, maybe they planned for a clean 20GB?
2. Sony might have planned for 1650GB of flash and went with 825GB instead. (12ch weird capacities)
3. Rumors are that sony was hesitating between 14gbps and 16gbps, if that's true, the memory cost rise would have seal the deal.
 
Last edited:
There does seem to be a restriction if the OS uses an IOMMU and enables virtualization-based security. It's possible the PS5 will, given the collection of other IO processors and DMA engines running freely in the SOC.
Whether Sony implements some other form of security measures around the PCIe subsystem, or the system software has other safeguards is probably something Sony wouldn't discuss. Sony has displayed surprising amounts of neglect in its security schemes before, however.

The m2 slot's PCIe link goes to the IO block on the main SOC, same as the custom SSD does.
We know that decompression and priority arbitration would be handled in that complex, and while I don't recall a mention of decryption, I think the most likely place for encryption and tamper checking is on the main SOC. That should give some defense of the data in persistent storage, barring security flaws or Sony's already mentioned neglect.

I'm not clear where the Tempest block is, or where its DMA might be.

Left unsaid is where the OS and firmware are being loaded from or into. I'd like to think Sony learned something from how stringing the boot process over the link from a separate southbridge compromised security.
We'd need to find out whether there's still a southbridge chip, since at least one of its functions was serving as a controller for the HDD, which the PS5 would have on-die.

Yeah if they use a IOMMU properly they should be able to remove the threat, the only problem there is that it is famously difficult to actually get a IOMMU working properly to close this type of hole (although it can be done). In the least this will allow researchers to fuzz the PCIe bus easier without having to cut or intercept traces unless Sony sets up some sort of system to interrogate the device that is attached, but even then its really only a matter of time until it is bypassed.

It opens a whole range of attack types outside of just doing DMA attacks depending on how a whole bunch of the operating system and hardware is implemented, but we will have to wait and see if they pan out.
 
At first I was hoping for an additional DDR4 pool dedicated to the OS; and that may still be a better choice. But I was thinking -- seeing as the I/O is so fast -- it would be great if the bulk of the OS memory footprint can effectively reside in the SSD and the second you press the PS button it dumps a small chunk of the game footprint into the SSD, replaces it with the OS footprint and then when you go back to the game, switches it back again.. This would effectively make the vast bulk of the 16GB GDDR6 available to games. If you can bring gigs worth of assets into your FOV in a second; I'd think the same approach for dropping the OS in and out could be possible. There'd be boatloads of room for optimisations too given the decompression hardware.

Of course, this would represent a write function to the SSD every time you bring the OS up, which over a long period may have implications in wearing the SSD. So it may be a terrible idea depending on the longevity/durability of the NAND (something I have practically zero knowledge on).


I may very well be wrong, but I don't recall Sony explicitly mentioning the additional DDR3 in the OG PS4 around the launch period. In lieu of the above idea, perhaps there's some hope of it yet. I'd think 2-4GB of bottom of the barrel DDR3/4 on a small bus would suffice for a lightweight OS and take the load off the 16GB GDDR6.


Speaking of hope, would be great to have a bump from 14Gbps to 16Gbps chips, relatively speaking it's probably the easiest thing to modify at this very late point. I know, I know...I'm only setting myself up for disappointment. :cry:
 
This more or less contradicts what Schreier has been saying (or more precisely, relaying what developers have told him) and that is an unverified commenter.

There are thousands of developers in the industry. A great many are excited about the PS5. A great many are excited by the XBSX. A great many are excited by both. Depending on what department you are in, you may have a greater or lesser understanding of some of the specs and how some parts of the hardware works. Likewise you may have a far greater understanding and appreciation for how other parts of the hardware works.

A person working on AI for a game will have a different perspective than someone working on the level design or character design in the game. All of that in turn may have different views than the people working directly on the engine or engine tools. Or the guy who works on the UI and game interfaces. Etc.

And all those might have different perspectives from the project lead, who has to try to try give direction to all the disparate parts of a large project.

So, yes, I trust what Jason Schreier relays from what he hears from his developer contacts far more than some person posting in the comments section, but what he relays and what he hears isn't the whole story. Same goes for DF, they are well connected and I trust what they have to say even more than Jason Schreier but even then they don't have the full picture.

While we certainly have a lot more information related to each console now than we had a month ago, we still don't know a LOT of details.

Regards,
SB
 
There are thousands of developers in the industry. A great many are excited about the PS5. A great many are excited by the XBSX. A great many are excited by both. Depending on what department you are in, you may have a greater or lesser understanding of some of the specs and how some parts of the hardware works. Likewise you may have a far greater understanding and appreciation for how other parts of the hardware works.

A person working on AI for a game will have a different perspective than someone working on the level design or character design in the game. All of that in turn may have different views than the people working directly on the engine or engine tools. Or the guy who works on the UI and game interfaces. Etc.

And all those might have different perspectives from the project lead, who has to try to try give direction to all the disparate parts of a large project.

So, yes, I trust what Jason Schreier relays from what he hears from his developer contacts far more than some person posting in the comments section, but what he relays and what he hears isn't the whole story. Same goes for DF, they are well connected and I trust what they have to say even more than Jason Schreier but even then they don't have the full picture.

While we certainly have a lot more information related to each console now than we had a month ago, we still don't know a LOT of details.

Regards,
SB

It’s hard to get developers to agree on previous architectures in hindsight. Even consoles that were near universally liked by consumers have many detractors on the development side. This gen will be no different. I saw one interesting comment that suggested prioritizing SSDs prioritized pre-made content over procedural content. If you’re focused on procedural games an ssd doesn’t help you as much as memory and compute power. But if you’re making a more cinematic game, linear or open world, the the ssd is your new friend.
 
There does seem to be a restriction if the OS uses an IOMMU and enables virtualization-based security. It's possible the PS5 will, given the collection of other IO processors and DMA engines running freely in the SOC.
Whether Sony implements some other form of security measures around the PCIe subsystem, or the system software has other safeguards is probably something Sony wouldn't discuss. Sony has displayed surprising amounts of neglect in its security schemes before, however.

The m2 slot's PCIe link goes to the IO block on the main SOC, same as the custom SSD does.
We know that decompression and priority arbitration would be handled in that complex, and while I don't recall a mention of decryption, I think the most likely place for encryption and tamper checking is on the main SOC. That should give some defense of the data in persistent storage, barring security flaws or Sony's already mentioned neglect.

I'm not clear where the Tempest block is, or where its DMA might be.

Left unsaid is where the OS and firmware are being loaded from or into. I'd like to think Sony learned something from how stringing the boot process over the link from a separate southbridge compromised security.
We'd need to find out whether there's still a southbridge chip, since at least one of its functions was serving as a controller for the HDD, which the PS5 would have on-die.

If it is like in the patent tamper checking it is working like this.

https://www.resetera.com/threads/ps...nd-sonys-ssd-customisations-technical.118587/

When the SSD has checked its retrieved data, it's sent from SSD SRAM to kernel memory in the system RAM. The hardware accelerator then uses a DMAC to read that data, do its processing, and then write it back to user memory in system RAM. The coordination of this happens with signals between the components, and not involving the main CPU. The main CPU is then finally signalled when data is ready, but is uninvolved until that point.

yUFsoEN.png
 
Dumb nitpick, but anyway, the whole point of my post was we'll see how open he was about the specs when we see what the clock impacts really are.

I don't know how anybody is going to know this unless devs or Sony chose to share it. Perhaps at a future GDC or GameLabs.
 
Sony seems like they are making the same mistake as they did with the PS4 Pro...i sincerely hate how they have lowered the priority on overall bandwidth when that will affect the potential of the entire unit far more than the marginal GPU or CPU clock differences in comparison to XBSX...

Is there anyway to mitigate it in time?

PS4Pro was bandwidth starved for days and that affected the resolution differences that were seen far more than the GPU disparity
 
in one the first wired articles, wasnt mentioned the RAM bandwidth per tflop?. I tried to look for it with not success. That would give us a clue if if was downgraded. I want to remember 50 GB/s per Tflop...
 
Either he's clueless or Cerny didn't tell everything about the Tempest-engine, since I'm pretty sure he referred it being a single customized Compute Unit without caches.
That thing isn't "as powerfull as whole PS4 brains" (assuming brains means the CPU here), it might do some specific task as fast as PS4's Jaguars might, but that's only because it's well suited for the types of calculations it needs to do and x86 CPU isn't that fancy for the same type of stuff.
 
There are thousands of developers in the industry. A great many are excited about the PS5. A great many are excited by the XBSX. A great many are excited by both. Depending on what department you are in, you may have a greater or lesser understanding of some of the specs and how some parts of the hardware works. Likewise you may have a far greater understanding and appreciation for how other parts of the hardware works.

A person working on AI for a game will have a different perspective than someone working on the level design or character design in the game. All of that in turn may have different views than the people working directly on the engine or engine tools. Or the guy who works on the UI and game interfaces. Etc.

And all those might have different perspectives from the project lead, who has to try to try give direction to all the disparate parts of a large project.

So, yes, I trust what Jason Schreier relays from what he hears from his developer contacts far more than some person posting in the comments section, but what he relays and what he hears isn't the whole story. Same goes for DF, they are well connected and I trust what they have to say even more than Jason Schreier but even then they don't have the full picture.

While we certainly have a lot more information related to each console now than we had a month ago, we still don't know a LOT of details.

Regards,
SB
That’s all valid, but it’s beside the point of whether you should believe a random common from a “developer” on the internet. All those fake spec leaks. Those were “developers” too ;-)
 
Back
Top