It's split into two speeds and two sections but not in a traditional sense like PS3 was where it caused a lot of head aches for memory management.
I actually think a lot of people are looking at it like old style memory systems, where you needed vast amounts of memory. You just don't with these setups, that's the whole point.
geordiemp
I didn't mean you, I mean just in general.
Want to add to this real quick...I think MS said that the two pools are tailored towards their particularly mentioned purposes, but aren't hard-set to them, correct? So technically, you can have non-GPU data on the fast pool, and graphics data on the slow pool..if you want. Seeing how I believe the split pool is kind of there for XBO X BC (read a theory on that somewhere..actually I think DF themselves mentioned this, can't recall), I would assume the pools can be used for whatever purpose dev consider best-fit for them.
I think some people are only looking at the pools in an "all or nothing" use-case; the 336 GB/s pool means you MUST be processing 6 GB of physical data, the 560 GB/s one 10 GB of physical data, etc. But it's actually kind of rare when the GPU or CPU will need that much data to process in a given access. If the memory setup between the two pools is as flexible as I think it aught to be, then if there's CPU-bound data that is, say, 2 GB in physical size, it might only need 112 GB/s bandwidth...why not put that data in the 560 GB/s pool of two of the 1 GB chips or upper 1 GB boundary of two 2 GB chips? That is, of course, if you need the data accessed that quickly,
but particularly if you may or may NOT need it that quickly while still needing the GPU to process data at a larger amount and faster bus rate than what the 336 GB/s pool can provide.
Dunno; there's something to XSX's memory setup I feel hasn't been fully disclosed or maybe even properly conveyed. It would not make sense to me to hard-set 10 GB for only GPU use and 6 GB for non-GPU use, when the only thing really defining the two pools of memory bandwidth are how many chips have enough physical capacity to define the slower pool (six chips, or 336 GB/s combined bandwidth). The only time the 336 GB/s pool would be an issue is if you have more than 3 GB of physical data for the GPU to operate on, but even so that is still 3 GB of graphics data spread on 3x 2 GB chips that each give 56 GB/s bandwidth, could you not just arrange that data so that, if 112 GB/s bandwidth is okay, 1x 2 GB chip holds 2 GB of that physical data and another holds 1 GB of it?
From that angle I feel the way MS has described could be more in what they are speaking of in regards to optimized placement of data on the modules and along the bus, because the GPU is going to be the most bandwidth-demanding component of any part of a console design, and larger GPUs need larger bandwidths. But IMHO it feels like that was them describing an optimal arrangement of bus utilization, but the reality should (hopefully) be a lot more flexible. For communication reasons tho I can see why they mention the split pool because you can't technically say "16 GB @ 560 GB/s" when people are expecting 2 GB modules and no combination of 2 GB modules on a 256-bit or 320-bit bus gives you 16 GB physical memory
AND 560 GB/s bandwidth.