That's interesting. So correct me if I'm wrong but, the way described here makes it sound like any data intended for the GPU and its memory pool needs to be in the "slower" memory pool for CPU & audio, which seems more or less like how things are typically done on PC with data going in the system RAM and copied to the GPU VRAM. But we also know that newer GPUs will have ways of avoiding this step with things like GPUDirectStorage and DirectStorage.
Again maybe I've misinterpreted but that sounds to be what is the case with Series X's memory setup. The main difference being that data isn't getting shuffled over PCIe. I'm...not exactly sure how this will pan out, but it certainly sounds like it comes with a good number of complications that could've been avoided by just going with 20 GB of memory. I assume the costs in developing, implementing and deploying VA would still be less than that extra 4 GB for all Series X systems, but it does also sound like this adds some extra work for developers to manage, which can be tricky when time is money.
edit: ignore this reply lol btw. it's completely based on wrong information.
Right, memory that is allocated to the GPU may actually need to be allocated to the CPU, but because of the split pool, developers can't use it and need work arounds to reallocate memory to it. The way memory is mapped, developers can't just freely use what's available without planning or designing around it. Instead of filling a single bucket, now they got two separate buckets to play with. Most of the earlier discussion around the disadvantages around split pool tended to formulate around the 'average' bandwidth between two pools, but size considerations were never really discussed (and honestly, without access to documentation I wouldn't have suspected this either)
The issue is likely going to be cropping up the most during the transition period of games. These are games that still traditionally use the CPU for a lot of GPU functions, like culling, animation etc. So if the CPU needs to access these memory locations, this information needs to sit in the slow pool for it to do it's updates etc. I think the traditional thought process here is that GPU needs a huge amount of memory, which it may in the future, but as of this moment with cross gen, you may not see so much budget being placed towards super high quality assets, so the amount of VRAM required by the GPU may be lower, like 7-8 GB. And the CPU may use the rest. But with Series X|S you are locked with how much you have in both areas, so you careful planning on how to do it which is difficult when you need to make considerations for last generation.
This may explain why there are random major drops on XSX with some of these launch titles. They simply ran out of room on the CPU or GPU side and needed to perform some terrible workaround to get it all to fit. ie, relying on the SSD to stream level/animation/vertices data in for new monsters etc while slowly unloading parts of the level out.
That being said however, the most critical features for GPU dispatch are included in the older generations of hardware (at least for Xbox One it is confirmed and for PS4 sort of assumed), so it's really about re-writing their rendering pipelines as PC is holding them back in this regard.
In the end it's only speculation, but just my thoughts on the performance on Series X|S so far. If (or rather) the games that can get to/using GPU driven pipelines: animation, vertex, culling, ordering etc, can all be performed by the GPU, improving the bandwidth by moving that particular data to GPU optimal memory, removing it from the standard memory pool, and freeing the CPU up to do other things or do a better job at holding higher framerates, working on AI or processing other things.
It's not Velocity Architecture that needs to be adopted really. I mean, that's one way to attack the issue, but that's a texturing solution. What about mesh information? Animation information? What needs to be addressed is the move to GPU driven rendering pipelines.
