The Xbox 1's ESRAM

would depend on how big the data block is . IF your working on something that doesn't fit in 6mb but fits in 32 then you should see big gains but will most likely loose performance as the block gets bigger than 32megs.

 

The CPU cannot access the eSRAM as far as the leaks say, only the GPU.

 

I don't think you'll gain that much tbh. the 32MB eSRAM only has a 30GB/s link to all 8 jaguar cores and each jaguar module (4 cores) can only read/write at 20GB/s at most.

 

The diagram does not indicate that AFAICS. How are you drawing that conclusion?

 

What why not? At 60 fps the cpu could deliver 512MB per frame... thats 16 times the size of the ESRAM.

 

Because we are talking in the terms of a cache there, speed wise its pretty slow. You'd get the exact same speed going to the DDR3 you'd just have a higher latency.

 

It would be an additional cache on top of the main memory. 30GB/s would be plenty.

Low latency is the point for a cache, but would there not be added latency for the CPU accessing eSRAM here, since it's for/on the GPU?

 

Again the diagram does not indicate that its not accessible by the cpu anywhere on it. Not in symbology, or in diagram form. What about that diagram indicates what you stated?

 

Perhaps he meant not directly...

 

I don't even see that. He seems pretty sure but the proof can't be that document.

 

Vgleaks mentioned that esram must be flushed before it can be accessed by the cpu.

But for gpgpu purposes does that matter? CPUs use caches to avoid calls to main memory. How does moving general tasks over the gpu alleviates the need for that avoidance? Gpgpu isn't just about making a gpu suitable for general purpose code. Its also about using a gpu to accelerate those tasks.

Accelerating general purpose code would seem to me to warrant cache increases in the gpu.

Isn't parallelizing traditional gpu tasks easier because the workload tends to be composed of more independent operations than found in general purpose code? Would the general mechanism for hiding latency on a gpu be suitable for all forms of gpgpu code?

I remember there was a paper called CPU assisted GPGPU, where a contributor was AMD. And it talked about using the caches on the CPU to facilitate the memory needs of gpgpu tasks on an APU.

 

Well the 30 GB/s through the northbridge would be plenty if the GPU memory system doesn't introduce much more latency. Can the cpu directly send data from through the northbridge to the gpu without touching ram?

 

Well since the 30gb connection says coherent read and write which is a totally separate and independent path from the Main RAM...i would say yeah.

 

It seems pretty clear to me. The eSRAM is local to the GPU and indirect to the CPU. Every system is connected to the rest through some pathway, but getting from A to B doesn't always mean it is fast or efficient.

 

I understand that. There is still nothing about the diagram that supports your original claim. From the writings of various developers it seems the opposite is true.

 

My claim is simply the CPU doesn't utilize the eSRAM, is that news? It is clear to me in that diagram and If you read the VGAleaks Durango memory article they only mention eSRAM with regards to the GPU. So which devs have broke NDA and discussed how the eSRAM is used?

 

No one broke NDA. Just descriptions of how the ESRAM could should be used. The descriptions are spread throughout the site in the various Durango/xbox one HW threads. Lots of insight from sebbbi and Gubbi in particular. You could be right but your hypothesis is the first I heard since discussions of the esram have been going on in earnest. No one iirc has ever said that the ESRAM was inaccessible by the CPU.

Of particular note were several discussions related to internal bandwidth and the overall memory subsystem. Your point of view never came up which is why I'm inquiring.

 

I've read those discussions, they were some time ago before any details leaked. If anyone else wants to add their insight, I'd be happy to read it. I thought after the VGA leaks it was just apparent the eSRAM was part of the GPU sub-system, just like in the 360.

 

There is no dispute that the esram is on the same part of die where the gpu is and behind the graphics memory controller. But my understanding, based on those conversations, particularly the ones where the 30gb/s pathway was discussed in terms of adding to the 200gb/s bandwidth claim was that the CPU and gpu could both access the ESRAM and the system RAM. Now with your assertion in questioning my recollection.

Either way its not clear from the diagram even with the acknowledgement of gpu managed coherency. You could be right. I just don't know.