geordiemp
@psorcerer @Rolling_Start
thicc_girls_are_teh_best
I figured out Lady Gaias math, it checks out
Let's start with PS5:
CPU 48GB/s speed is an average, it can actually access 48GB in 0.1071428571 seconds using the full bus capacity, 0.1071428571 seconds of GPU access stalls equals 48GB/s (448*0.1071428571), so the net loss is 48GB/s. Giving the GPU an average of
400GB/s speed
(38.9GB/s per TF)
XBX
- CPU can access 48GB in 0.1428571429 seconds if the data is on the SLOW pool - 0.1428571429 seconds of GPU access stalls equals 80GB/s (336* 0.1428571429). Leaving GPU with an average bandwidth of 480GB/s (39.6GB/s per TF)
- CPU can access 48GB in 0.08571428571 seconds if the data is on the FAST pool - 0.08571428571 of GPU access stalls equals 48GB/s (560*0.08571428571) Leaving GPU with an average bandwidth of 512GB/s (42.3GB/s per TF)
In scenario 1: CPU data (system memory) is allocated on the slow pool for a total of 13.5GB available ram for games.
In scenario 2: CPU data (system memory) is allocated on the fast pool limiting total available memory for games to only 10GB.
Interesting, and appreciated. I'll give a look over this sometime when able. One thing though: why would only 10 GB of data be available for games in Scenario #2? I don't think that would make good sense from an engineering POV, even as a compromise for going mixed 1 GB/2 GB modules.
Dunno, something feels like info on the memory setup is still not fully understood, I would assume the system would allow for data access from both pools. Hopefully MS fully divulges on the memory setup in the near future because I think a lot of these analysis, while well-informed, are operating with the absence of crucial information. If not, MS probably needs to splurge for full 2 GB chips and eat the costs because the setup as mentioned here sounds like it'll be very constrictive for the GPU in due time.
The chips themselves aren't actually slower. By slow they mean the bandwith dedicated to the GPU 10*56 versus dedicated to CPU 6*56.
The chips themselves are actually all the same speed.
See this is one of the things we need full official clarification on; when MS mentioned the memory setup I took it as them saying the "fast" pool was "orientated" for GPU data, and the "slow" pool for CPU and other data...but not the pools being hard-set for that type of data.
The reason I bring that up is because DF also mentions that the "slow" pool is somewhat implemented for Xbox One X BC, so obviously that would mean both graphics/GPU and non-graphics data is being stored in that "slow" pool for that given instance. Why, then, give that type of flexibility to the "slow" pool for BC purposes, yet hard-lock it for only CPU access with XSX games?
Makes no sense design-wise, so I'm inclined to believe the use of the "fast" and "slow" pools are use-cases MS assumes most devs will use them for, especially in consideration of how much GPU-bound data they may need for a period of time. But that probably doesn't mean the two pools are hard-locked to just those purposes, among other things.
Hopefully there's more clarification soon.
First world hyper-micro problems.
www.youtube.com
