I’m strictly speaking of the Menu screen here, accessed during games via the Homo button. Surely this can be slow enough while not being a nuisance? It’s relatively slow now and that’s ok, no?
Playstation 5 [PS5] [Release November 12 2020]
- Thread starter BRiT
- Start date
Yes, 448 GB/s.
I haven't coded in assembly in a long time so anyone can come in and correct these mistakes. Commonly named, there 2 types of classes of memory is called a Stack and Heap. I usually like to associate Heap with Main Memory and Stack with Cache. But that's probably not correct.
Or in other words
int x = 1; is the stack
Object y = new Object(); is the heap
Sometimes you can hold larger structures in the stack, using things like struct, which isn't quite an object. As long as it can fit in the stack I think you're good.
I've never known a time in which the stack has been overfilled; but other members can chime in. Each core/thread has it's own stack IIRC. The more I think about it, the stack is almost like the program and the program counter and moving about.
Anyway, it's not important, it's just put into focus that we need both and the stack is much faster than the heap.
So generally speaking the heap is system memory, we still do a lot of reading and writing to the heap all the time.
So if I were to say make a PS5 UI.
we would have a pointer to it called UI PS5ui -> pointing to the memory location of the object holding PS5UI.
when I want it to show the home screen I would call a function that would parse the PS5UI data. In doing so we would need a lot of function calls will be necessary to render different aspects of the UI. All of it loading different aspects of the memory up and having ot go back and forth to _write_ to the memory not just read. Because somewhere we will need to update the UI as we make changes to it; for instance a news feed update, or a trophy update, or store updates, screen shots, pictures etc all need to be readily accessible. All sorts of things are constantly being updated on our UI, the states of things, the last thing we had highlighted, the last menu we were at.
We need to write these values somewhere and it's can't be the stack, it must be the heap and it must be the PS5 UI Object.
In this sense, this constant writing and reading of small block memory is very normal for system memory to do; this is it's purpose.
This type of behaviour is not good for SSD. It is designed to be writing all blocks in a row and reading huge blocks in a row. Its random performance is quite terrible compared to it's sequential read/write performance. How a user will use the UI is random, much like an OS. We cannot predict how they will use it. So if we are grabbing the full UI memory location each time to process something small, we have huge inefficiencies. Then we need to factor in seek times and then round trip latency for all the reading and writing you will do. It will be very sluggish imo.
So despite it having large bandwidth, it's going to be really bad to use as system memory.
Mihailjones
Newcomer
(I think you are describing something else than I am below)
Ideas that I have seen arent about using SSD as system memory, more like storing "image of system memory to ssd" which is different thing, right?
Like have static partition or reserved space on SSD
lets say it is 3GB and every time user is in game -> RAM that OS uses is saved on that space as whole
-> 3Gb of RAM is now freed for the game
-> user presses Home button -> 3GB chunk of data is loaded from SSD -> desktop works again
of course it needs to free up that 3GB from game code and there are processes that need RAM all the time on the background, but as a concept something like that.
So it is not using SSD as RAM, or having to seek random stuff from there, more like just using SSD as fast place to just save & load same "block" from ram every time. And I am assuming that the state of GUI is easily available on this "block of data".
Sure, I guess everything is doable, whether it makes sense or not is a different question.
I don't know how much space the UI takes in memory, but the OS I mean, it controls a lot more than the UI.
The games use OS functions as well.
Things are constantly running in the background etc. I don't think it's a good idea to pull the OS out of memory. Generally speaking I think the use cases for that are limited to some very specific small IoT devices.
I think they would have at least a fixed 1GB for the OS maybe more, but any apps can be swapped in one second when popping the menu, just like ps4 pro does to the ddr3 area when going back to the system menu.
Games have a lot of buffers that are for rendering. So when pausing the game these should be easy to release and rerender when unpausing.
Games have a lot of buffers that are for rendering. So when pausing the game these should be easy to release and rerender when unpausing.
Is it worth the extra wear on the flash cells?
A question, the PS4 (and x one?) have a seperate arm CPU for tasks when in standby mode, to update and download patches etc. When the PS4 is not in standby mode, is that arm CPU used for the OS background tasks, or only in standby mode?
In that case, with the PS5 (and XSX), a seperate arm CPU is not present, because its not needed anymore?
In that case, with the PS5 (and XSX), a seperate arm CPU is not present, because its not needed anymore?
But isn’t that also true for any time we stop playing a game then? We write the current state to SSD and when we go back to it, the game is resumed. That will also be an issue in the long run, as I suspect we will be using rest/resume thousands of times over a few years?
I don't think either PS4/XBoxOne actually use the ARM core during standby mode for patches. It might use it to check to see if updates are available etc, but neither one can use it to do the actual patches. I'm not sure if either current-gen can even use it to do just the downloads.
So what's it for, and when is it used? Does it free up CPU resources during gameplay, by letting the OS use the arm core (and its memory)?
Entertained the idea that it was used for background and OS tasks, because wikipedia said so (for many years?), i know wikipedia...
https://en.wikipedia.org/wiki/PlayStation_4_technical_specifications
It does link to a source which is unavailable. Anyway, i think the PS5 and XSX can live without any arm cpu's.
The PS4 already had a smaller DDR3 module off its southbridge chip, for use by the OS running on it. Since that chip acted like an IO device from the point of view of the APU and main OS, the Pro expanded the size of the DDR3 module and made that capacity available as a temporary buffer for data not in use when the game is in the foreground.
There's zero physical seek time, but the NAND modules have non-zero latency. I've seen best-case references to tens to hundreds of microseconds, depending on the quality of the drive, choice in NAND type, and access patterns. DRAM's best-case latencies are in the tens to hundreds of nanoseconds.
There are also worst-case numbers that can be pretty bad, even if not quite HDD bad. Some functions like the home/game transitions might be acceptable if they are on human time scales, but functions with internal system use be kept in main memory.
The PS4's southbridge chip had a few known uses. It plays some part in the boot process and security of the system, it virtualizes or impersonates a number of x86 system devices, it helps load balance network and HDD traffic (might be what enforces the PS4's HDD bandwidth cap), and serves as a low-power platform module for connected standby.
Most of the connected standby or system service elements not related to wake-up, security, or device level sleight of hand were dropped, allegedly due to insufficient performance.
Depends on the number of times and how much is being written.
For example, let's assume we're writing back 16 GB/s per switch operation. You could do that 64 times before exhausting the capacity of a 1 TB drive that for simplicity's sake I'm assuming is fully available just for this purpose.
If a user performed that kind of writeback of 16GB at 16 times a day 365 days a year, at the end of 10 years the NAND cells would have been written a little over 900 times, which is near the marketed limit of QLC flash. It's not clear yet what level the consoles are going for in terms of NAND density.
Things done a few times per day could be handled, depending on how much capacity is really available and how much other write traffic besides context switching is going on. Things that happen at a higher rate quickly fall under the category of things the console is going to keep in memory.
Similar threads
- Locked
- Deleted member 7537
- Games Industry
- Sticky