esram astrophysics *spin-off*

Status
Not open for further replies.
The minimum given at hot chips was 109GB/sec which you can only derive using the new clock.

1024bits x 853MHz ~ 109. The 204 still doesn't add up
 
Last edited by a moderator:
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.
 
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.

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 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
 
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

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.

the 133gb and 192gb/s are the question mark numbers.

I understand he said those numbers and hes the PR but be stated categorically that the engineers will eventually answer all technical questions. If thats what GAF needs to be convinced then so be it.
 
Sorry for being obtuse but would a clock boost automatically warrant a boost in esram bandwidth?
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.
 
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.

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.
 
You're doubting the possibility? I don't see why'd they bother lying to X1 devs first. People who have the hardware.
 
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.
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.
 
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 hope at some point we get some answers at any rate here is an article from ARS Tech on the subject:

http://arstechnica.com/gaming/2013/...s-xbox-one-from-accusations-its-underpowered/
 
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)?

The leak was based on that you can't do R/W simultaneously.

Therefore when doing ESRAM->ESRAM, BW was divided in the middle, 102.4/2 = 51.2.

When doing ESRSM<->DRAM, the limit is bound by the DRAM, therefore, 68.2, even when the theoretical BW on the ESRAM is 102.4.

If you are curious about how the design could be and how the math can line up correctly, go back previous page and read #212.
 
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.

Believe him? I don't have a problem with the inquiry, I have an issue with discriminatory tone from some people stating that Penello is either shading the truth or outright lying. As if his job is to prove anything to them.

You do realize that except in very brief circumstances ps4 will not achieve 176gb/s utilization with any regularity? Why don't you ask Cerny what their real world bandwidth figures look like while we are making demands. :rolleyes:
 
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.

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/

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/

The ~133 GB/s number was pre-uptick. Between 140 and 150 GB/s seems to make sense post-uptick. It's strange how Leadbetter's article seems to imply it is not a normal throughput (i.e., an outlier for certain post-processing operations) where Charlie's says otherwise. Charlie also seemed to think that they overclocked the CPU at ~1.9 GHz when in fact it was a more modest 1.75 GHz (see semiaccurate).
 
Status
Not open for further replies.
Back
Top