It is logical, MSFT chose a GPU, its specs (# CUs, # ROPS, size of L2, etc.), then run lots of simulations to put together a quite complex SoC which include 2 Jaguar compute cluster, lot of SRAM, a massive sounds DSP, etc.
Well I would also think that GPU have gone a long way since then and in direction that seems to please both Sony and MSFT.
No. The memory controllers are 64bits wide and comprised of two 32bit channels. The L2 can actually transfer 64 byte between each L2 tile (there is one tile per memory channel) and the multiple L1s (each one has also a 64byte/clock bandwidth). There is a massive crossbar inbetween. The bandwidth between an L2 tile and the accompanying memory channel (running at core speed) is not officially disclosed by AMD, but the 256bit from the Durango documentation on vgleaks looks reasonable for that (it's never going to be a bottleneck when it is faster than the memory). One need to compensate for the very high speed of the GDDR5 over narrow interfaces. That means the internal busses running at the nominal clock speed need to be wider than the memory interface itself. And this also means that discrete GCN parts probably need 256bit connections per L2 tile and 32bit channel and not 256bit per L2 tile and 64bit controller as Durango is obviously using (but maybe it's the same setup as with other discrete GCN parts and that is a fuckup in the diagram as this 4x256bit could never transfer more than 102.4GB/s [or there is a separate interface to the eSRAM not running over those 4x256bit] and MS claims an aggregated read speed of ~170GB/s, falls inline with the fact that MS apparently didn't know how fast their eSRAM actually is
).Maybe (or not) they saved a bit on that front counting on the lower speed of DDR3.This is not exactly clear and depends on how MS decided to draw the block diagram (they took strange decision for the SIMD setup, too; they also managed to give borderline [in a strict sense wrong] descriptions of the scheduling of instructions in GCN).
/*
* CP.
* On CIK, gfx and compute now have independant command processors.
*
* GFX
* Gfx consists of a single ring and can process both gfx jobs and
* compute jobs. The gfx CP consists of three microengines (ME):
* PFP - Pre-Fetch Parser
* ME - Micro Engine
* CE - Constant Engine
* The PFP and ME make up what is considered the Drawing Engine (DE).
* The CE is an asynchronous engine used for updating buffer desciptors
* used by the DE so that they can be loaded into cache in parallel
* while the DE is processing state update packets.
*
* Compute
* The compute CP consists of two microengines (ME):
* MEC1 - Compute MicroEngine 1
* MEC2 - Compute MicroEngine 2
* Each MEC supports 4 compute pipes and each pipe supports 8 queues.
* The queues are exposed to userspace and are programmed directly
* by the compute runtime.
*/
[..]
* KV: 2 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 64 Queues total
* CI/KB: 1 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 32 Queues total
*/
if (rdev->family == CHIP_KAVERI)
rdev->mec.num_mec = 2;
else
rdev->mec.num_mec = 1;
rdev->mec.num_pipe = 4;
rdev->mec.num_queue = rdev->mec.num_mec * rdev->mec.num_pipe * 8;Quite sure 4 ACEs with 8 queues each (32 queues in total), FLAT memory addressing, some extended debugging features, and some new instructions. Very likely also the volatile flag, memory address watch, or in short, basically everthing in that CI manual which was online for a week or so. They just have half of the 8 ACEs stated (probably as maximum) in the manual.
The pair of new asynchronous DMA engines mentioned in the text sound like they are derived from the DMA engines from before and/or have been exposed for programmer control.
