Archie explained everything, now I have nothing to say
I'll just blab a little anyway.
Though for VIF1 the involved DMA Channel is ch1 and asfaik it seems to be uni directional (mem --> vif1).Can the VUs LSUs address all memory(local, DRDram, mm-registers), or just their local ones.?
VU's operating in Micro mode only see their local memory. But the VIF1 channel in fact is bidirectional as it's also used to read GS memory.
Moreover, all VU micromemories are main memory mapped, so you can both read them directly via cpu or with other utility DMA channels.
But it should be noted that paths from VU1 aren't there for much more then debug purposes - you have a direct path from VU1 to rasterizer for a reason.
Why would you want to read the memory back in the first place btw?
Btw reg. address size, whats the systems virtual address size and why would you need virtual addresses on such a system (r5900s caches are virtually indexed)
Virtual address size is also 32 bit. Anyway, I'm pretty sure those features are standard on the said MIPS family of cpus, and the r59k core isn't a major redesign. If you look at Gekko in GCN, it brings over some very similar legacy from the 750cx PPC core that fathered it.
On the other hand, it doesn't hurt to have that when you run a HDD and Linux on the machine
having a 3.2GB/sec memory sub-system on a 2GB/sec bus seems to be a strange design desicion, as all kinds of other data(e.g. IPU --> GIF, SPRAM --> VU1) also have to use that pipe, esp. when taking into consideration the near absence of caches in EE.
That'd be 2.4gb bus
Anyway, one Tohiba's paper discusses efficiency of varius ram types, and RDRam part kind of like the one found in PS2 is rated around 70% - which would give you almost exactly 2.4gb... coincidence?
The edram seems to have two access ports for the framebuffer (1024bit read & write..). Does this mean you can interleave fetches and writes to the framebuffer (how long is edrams access latency then??)?
There are 3 access ports (512bit texture read also), connected to 2 page buffers (texture/frame). There doesn't seem to be any documentation on actual latencies, but if my understanding is correct, as long as you hit pagebuffer there shouldn't really be any to speak of.
Page breaks are another matter, page refill happens at around 150GBytes/sec, which gives you 8cycles per page for transfer, + whatever is added by access latencies(again, I have no info on those).
Marco,
PS. saying consoles with embedded framebuffers, in addition to seperate main memory, use UMA seems disingenuous.
I was refering to type of processing flow - at any rate, it really boils down to semantics. Sony themselves call PS2 'hybrid UMA', and imo, for a good reason.
Devices in the system feed of a single memory pool, their local buffers operating as scratchpads/caches.
In the end it just comes down to implementation differencies in memory bandwith saving techniques. Ie. - big dumb embeded buffers versus smaller smart caches.
Or in case of GCN, a cross between both...
