The Xbox 1's ESRAM
- Thread starter LoStranger
- Start date
Betanumerical
Veteran
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.
Betanumerical
Veteran
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.
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.
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.
Last edited by a moderator:
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.
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.
Similar threads
- Sticky
