System Reservations on PS4, 4Pro, PS5, XBox One, One S, One X, and Xbox Series X|S [2019-12, 2020-03]

BRiT

(>• •)>⌐■-■ (⌐■-■)
Moderator
Legend
Supporter
What are the current system reservations on current-gen systems such as PS4, PS 4Pro, and Xbox One S, XBox One X?

I seem to have misplaced my SDKs and searching/googling is drawing hits from pre-launch 2013, so I'm hoping the community can help out with this question.

I'm looking for things like the 20% to 50% of the 7th CPU Core and 100% of the 8th CPU core and time-sliced 2% of all GPU CUs is reserved for OS/Dashboard use. These may not be accurate numbers, but I wanted to show what info I'm looking for.

If you can also list initial reservations and how they changed over time, you'll get bonus likes. ;)

Thank you,

---
Current-Gen Reservations

Xbox One
Around early 2014 Microsoft changed System Reservation from time-sliced 10% GPU to 2% GPU. The initial 10% was broken down to 2% for Voice and 8% for Video, giving developers use of 98% of GPU.
Around late 2014 Microsoft changed System Reservation from 100% CPU Core #7 to allow for using only 20% to 50% of CPU Core #7, giving developers use of 80% to 50% of CPU Core #7.


PS4
Around late 2015 Sony changed System Reservations from 100% CPU Core #7 to allow for using only 50% of CPU Core #7 or 60% of CPU Core #7 if VR, giving developers use of 50% of CPU Core #7 or 40% of CPU Core #7 if VR.


---
Next-Gen Reservations

Xbox Series X:
1 CPU core (or 2 threads) reserved for OS/Dashboard
Games can use SMT or not; 8 physical cores at 3.8 GHz (SMT disabled), or 16 cores and threads at 3.6 GHz (SMT enabled)
The OS/Dashboard reserves 2.5GB GDDR6 memory from the 336 GB/s memory pool and 32 Meg from the 560 GB/s pool.

In terms of how the memory is allocated, games get a total of 13.5GB in total, which encompasses all 10GB of GPU optimal memory and 3.5GB of standard memory. This leaves 2.5GB of GDDR6 memory from the slower pool for the operating system and the front-end shell. From Microsoft's perspective, it is still a unified memory system, even if performance can vary. "In conversations with developers, it's typically easy for games to more than fill up their standard memory quota with CPU, audio data, stack data, and executable data, script data, and developers like such a trade-off when it gives them more potential bandwidth," says Goossen.

[ Sources: https://www.eurogamer.net/articles/digitalfoundry-2020-inside-xbox-series-x-full-specs ]

Series S:
1 CPU core (or 2 threads) reserved for OS/Dashboard
Games can use SMT or not; 8 physical cores at 3.6 GHz (SMT disabled), or 16 cores and threads at 3.4 GHz (SMT enabled)
The OS/Dashboard reserves 2 GB GDDR6 memory from the 56 GB/s memory pool and 16-32 Meg from the 224 GB/s pool.

Why are developers being told that it's 'hundreds of megabytes' more memory and not a more concrete figure? Since recording the Direct, I've discovered that the amount of memory is somewhat fluid. There's a block of new memory available to all developers, but this can be augmented by disabling system level features the game may not be using, freeing up extra memory that otherwise wouldn't be used anyway.

[ Sources: https://www.eurogamer.net/digitalfo...-memory-boost-and-the-massively-fast-rtx-4090 ]


PlayStation 5:
1.5 Cores (out of 8) reserved for OS/Dashboard
The physical cores run at 3.5 GHz or lower as SmartShift adapts.
The OS/Dashboard reserves 3.5GB memory.

As a counterpoint, I suggest that with 12.5GB of RAM available to developers on PS5 (at least at launch - and it's 13.5GB on Xbox)
[ Sources: https://www.eurogamer.net/digitalfo...-memory-boost-and-the-massively-fast-rtx-4090 ]

1666898273285.png
[ Sources: DF Gotham Knights PC video]
 
Your interpretation is incorrect for the 7th core on PS4 (this is from SDK 3 to 4.5):

Normal mode (foreground execution, the game is being played):
- 50% of 7th core is given to the devs
- 40% is allocated to the devs when it's a VR game

Low mode (game is put in background execution, dashboard is displayed):
- 10% of 7th core is given to devs
 
Thank you @Globalisateur .

Is there any sort of GPU time-splicing on PlayStation 4 series? Or does the OS/Dashboard use priority queue through ACEs (?) to handle that?
 
Thank you @Globalisateur .

Is there any sort of GPU time-splicing on PlayStation 4 series? Or does the OS/Dashboard use priority queue through ACEs (?) to handle that?
There is a time allocated to the system from each 16.67ms frame. I don't remember how much though.

EDIT: My fuzzy memory tells me 0.5 ms of GPU is reserved to the system. About 3%. But not 100% sure about it.
 
Last edited:
Found the source about 0.5 ms of GPU reservation (Sony confidential slides about Pro):

PS4-pro-gpu-and-memory-reserves.jpg
 
Does anyway know how the 3GB OS reservation is used? I know on XB1 launch, the OS was 2GB, and the other 1GB was the hypervisor + unused ram held for possible later use.

Pretty sure all apps use a portion of the 2GB, as the apps and game title run simultaneously.

With virtual memory I don't see why they need 3GBs for next gen. Why not designate a segment of memory as flexible, page out the app +OS foreground memory to disk.

I.e for Lockhart

768MB background OS memory, locked.
512MB background apps memory pool, locked.
768MB for hypervisor and expansion, locked.

Flexible memory: 2GB. Pages in and out of SSD on OS transition.

Title memory: 8GB locked.

When foregrounded, apps and OS have 4GB. When backgrounded apps and OS have 2GB.

When foregrounded, game title has 10GB.
When backgrounded, game title has 8GB.
 
Last edited:
For a straight port of the existing OS, I expect both Sony and MS to free up the 1GB or so occupied by the apps as flexible memory. Currently, both system allow a single instance of any app at a time. The previous instance is thrashed.

I expect the thrashing to be extended to game / os switching. With the SSD, loading should be quicker outside of app start network calls. Developers need to update their app to be paged to SSD to allow for fast resume.
 
IIRC, Xbox One allows for 4 running apps at a time with quick-switching between them.

There is still some quick switching between them, but that seems to still be going through a tomb-stoning process, but they launch quicker than they do from cold and they remember what spot they're in. I'm able to quick switch between XBox Rewards App, Forza Hub, Spotify, and IE and they all resume from exactly where I was at before.
 
IIRC, Xbox One allows for 4 running apps at a time with quick-switching between them.

There is still some quick switching between them, but that seems to still be going through a tomb-stoning process, but they launch quicker than they do from cold and they remember what spot they're in. I'm able to quick switch between XBox Rewards App, Forza Hub, Spotify, and IE and they all resume from exactly where I was at before.

Hmm interesting. I always thought it's single instance only.

Also I thought tomb stone was jargon for crash dump on Android?
 
Xbox Series X:
1 CPU core (or 2 threads) reserved for OS/Dashboard
Games can use SMT or not; 8 physical cores at 3.8 GHz (SMT disabled), or 16 cores and threads at 3.6 GHz (SMT enabled)
The OS/Dashboard reserves 2.5GB GDDR6 memory from slower pool

In terms of how the memory is allocated, games get a total of 13.5GB in total, which encompasses all 10GB of GPU optimal memory and 3.5GB of standard memory. This leaves 2.5GB of GDDR6 memory from the slower pool for the operating system and the front-end shell. From Microsoft's perspective, it is still a unified memory system, even if performance can vary. "In conversations with developers, it's typically easy for games to more than fill up their standard memory quota with CPU, audio data, stack data, and executable data, script data, and developers like such a trade-off when it gives them more potential bandwidth," says Goossen.

[ Sources: https://www.eurogamer.net/articles/digitalfoundry-2020-inside-xbox-series-x-full-specs ]
 
Xbox Series X:
1 CPU core (or 2 threads) reserved for OS/Dashboard
Games can use SMT or not; 8 physical cores at 3.8 GHz (SMT disabled), or 16 cores and threads at 3.6 GHz (SMT enabled)
The OS/Dashboard reserves 2.5GB GDDR6 memory from slower pool

[ Sources: https://www.eurogamer.net/articles/digitalfoundry-2020-inside-xbox-series-x-full-specs ]

I'm confused. If it's reserving, does it reserve based on the dev's choice? So if they want 8 cores, they only get 7? Or if they want threads, they only get 14?

And can you mix and match? ie: 4 cores full speed, 4 cores reduced speed but with SMT? (I'm pretty sure they can't but I wanted to ask)
 
If it's reserving, does it reserve based on the dev's choice? So if they want 8 cores, they only get 7? Or if they want threads, they only get 14?

That is how I understand it. One entire Physical Core [2 Threads] is reserved for the OS/Dashboard. The developers have access for up to 7 Physical Cores which might provide 7 Threads (SMT Disabled) or 14 Threads (SMT Enabled).

And can you mix and match? ie: 4 cores full speed, 4 cores reduced speed but with SMT? (I'm pretty sure they can't but I wanted to ask)

I don't believe so, or at least it wasn't discussed. That would be an odd breakdown depending on where the OS/Dashboard is reserved at --
4 Physical Cores @ 3.8 GHz + 3 Physical Cores (6 Threads) @ 3.6 GHz
3 Physical Cores @ 3.8Ghz + 4 Physical Cores (8 Threads) @ 3.6 Ghz​
 
I strongly expect that the dev can not mix the operation.
It's either only non threaded or threaded.
It will effect all cores including OS.
It only affects OS when game is running, and OS can run fine in background mode in either mode.
 
That is how I understand it. One entire Physical Core [2 Threads] is reserved for the OS/Dashboard. The developers have access for up to 7 Physical Cores which might provide 7 Threads (SMT Disabled) or 14 Threads (SMT Enabled).



I don't believe so, or at least it wasn't discussed. That would be an odd breakdown depending on where the OS/Dashboard is reserved at --
4 Physical Cores @ 3.8 GHz + 3 Physical Cores (6 Threads) @ 3.6 GHz
3 Physical Cores @ 3.8Ghz + 4 Physical Cores (8 Threads) @ 3.6 Ghz​

I wonder if MS could enable something like this if they chose to do so. But in an unconventional manner.
For instance, their game-switching technology. If you could run two instances of the same game, each having a different core config (instance 1 running 7@3.6+SMT, instance 2 running 7@3.8-SMT), with the current world state mirrored-to and updated on the non-active instance, with a switch between game instances determined by CPU load.
Of course, they would have to greatly speed up the process as it currently takes 2-4 seconds to switch games.
 
I strongly expect that the dev can not mix the operation.
It's either only non threaded or threaded.
It will effect all cores including OS.
It only affects OS when game is running, and OS can run fine in background mode in either mode.

this implementation seems weird to me as the extra clocks would only marginal improve perf were as multi threading allows better consistency though latency hiding. if i was designing the system i would enforce use of multi threading giving half of the threads to the kernel code and the other half the user application spiting the 2 way muti-threaded core down the middle. this would enable things like fast and more importantly non-blocking system calls and the better use of all 8 cores rather then only use 7 cores.
 
Does Zen2 allow to enable/disable SMT usage per CPU core?
Disabling SMT has remained a SoC-wide BIOS setting instead of a userland configurable parameter, so presumably no. A few core resources are statically partitioned, and AFAIK those have been designed to be configured only during SoC boot/init. You could check BKDG though if they have released any for Zen 2.

In any case, OS parking half of the logical processor cores can achieve the same effect.
 
I'd still hazzard a guess at something like 2 ~ 3 GB. Sony are going to need broadly the same amount of OS stuff in RAM as MS. Fast as the PS5 SSD is, it's still ass slow compared to RAM and has limited endurance for writes.
 
Back
Top