So Albert is saying the esram can read and write at the same time: http://www.neogaf.com/forum/showpost.php?p=80951633&postcount=195
He's also made several factually incorrect and self contradictory claims in that thread. He offers no explanation for how the simultaneous read/write is attained, or why it only apparently only occurs 7/8ths of the time.
I thought the 7/8ths comes from the fact that quoted bandwidth for the bidirectional ESRAM is not 2x unidirectional speed which is weird when the scaling is normally linearYou are conflating what was said here (7/8ths) with what he said (simultaneous read/write). He also doesnt have to provide ANY explanation as to how his engineers achieved that. The fact that you think he should is ludicrous.
I thought the 7/8ths comes from the fact that quoted bandwidth for the bidirectional ESRAM is not 2x unidirectional speed which is weird when the scaling is normally linear
If you ignore the clock bump that updated both the minimum and peak.depends on which numbers you use.
if you take the original 102 GB/s and make it two ops per cycle then you get his number.
If you ignore the clock bump that updated both the minimum and peak.
No, but when you have a BW increase that's proportional to the clock increase, it points a very strong finger to the eSRAM bus being on the same clock.Sorry for being obtuse but would a clock boost automatically warrant a boost in esram bandwidth?
You are conflating what was said here (7/8ths) with what he said (simultaneous read/write). He also doesnt have to provide ANY explanation as to how his engineers achieved that. The fact that you think he should is ludicrous.
You don't have to believe him. The only folks who have to believe him are the ones actually writing code on the box, and they have all the tools they need to verify his statement.It's ludicrous to want an explanation for why a piece of hardware can achieve nearly twice the performance it should be mathematically capable of based on their own description of the design? And why it's not actually twice the performance and instead an additional 7/8ths? He claimed simultaneous read/write and quoted the 7/8ths number at the same time. If he wants anyone to believe either then he should be able to provide some details on how this is possible or it will just make him look like a carpet bagger.
It's ludicrous to want an explanation for why a piece of hardware can achieve nearly twice the performance it should be mathematically capable of based on their own description of the design? And why it's not actually twice the performance and instead an additional 7/8ths? He claimed simultaneous read/write and quoted the 7/8ths number at the same time. If he wants anyone to believe either then he should be able to provide some details on how this is possible or it will just make him look like a carpet bagger.
Looking at the leaked documentation on VGLeaks (http://www.vgleaks.com/durango-memory-system-overview/), I'm not sure how MS now arrives at 109 GB/s (102.4 GB/s prior to uptick) being the minimum bandwidth available for the ESRAM and 204 GB/s (192 GB/s prior to uptick) being the maximum, when diagrams included in their prior documentation seem to indicate that the bidirectional read and write bus had a 51.2 GB/s max throughput for read and 51.2 GB/s max throughput for write? How can both read and write's throughput seemingly double to now handle 102.4 GB/s each (factoring in the uptick)?
It's ludicrous to want an explanation for why a piece of hardware can achieve nearly twice the performance it should be mathematically capable of based on their own description of the design? And why it's not actually twice the performance and instead an additional 7/8ths? He claimed simultaneous read/write and quoted the 7/8ths number at the same time. If he wants anyone to believe either then he should be able to provide some details on how this is possible or it will just make him look like a carpet bagger.
I believe in Leadbetter's article, MS themselves purported that the best real world throughput in an ideal alpha blending scenario was ~133 GB/s. I believe they also said that achieving simultaneous read and writes was on a limited basis and not how the ESRAM normally functions most of the time. I could be misinterpreting, however.
The reason for minimum and peak bandwidth counts are quite simple, unlike DRAM the embedded memory doesn’t have to go through all the bank tricks and other bits necessary to get any sane efficiency numbers. It is also much lower latency so any of the write coalescing tricks and other DRAM controller tricks would be pointless and trash the hard-won latency figures. In essence it would be counter-productive to do so. The down side of this is that if the code being run isn’t very good, and by that we mean lots of small (64b) reads or writes, the controller can’t utilize the extra width for anything useful so the bandwidth is wasted. If the running code is well tuned it will do all or at least mostly 256b transfers and possibly hit that 209GBps peak number.
To translate from technical minutia to English, good code = 204GBps, bad code = 109GBps, and reality is somewhere in between. Even if you try there is almost no way to hit the bare minimum or peak numbers. Microsoft sources SemiAccurate talked to say real world code, the early stuff that is out there anyway, is in the 140-150GBps range, about what you would expect. Add some reasonable real-world DDR3 utilization numbers and the total system bandwidth numbers Microsoft threw around at the launch seems quite reasonable. This embedded memory is however not a cache in the traditional PC sense, not even close.
Semiaccurate Charlie said they are achieving 140-150GB/s with the ESRAM regularly. Which I suspect is a similar percent of BW GDDR5 or any other type of memory achieves of it's peak.
This really implies it's a real, healthy figure and not some contrived case.
http://semiaccurate.com/2013/08/30/a-deep-dive-in-to-microsofts-xbox-one-gpu-and-on-die-memory/