esram astrophysics *spin-off*

Status
Not open for further replies.

astrograd

Regular
Sometimes there are strange coincidences. The XB1 gets an upclock to 16/15 of the original 800MHz speed and the eSRAM is rumored to have now a peak bandwidth of 15/16 of twice the original speed.

16/15 * 800 MHz = 853.3 MHz.
15/16 * 2*102.4 GB/s = 192 GB/s

Hmm. Food for conspiracy theories? :rolleyes:

Interesting thing to notice. :)

Maybe the eSRAM was found to double pump on 7 out of every 8 cycles due to the low latency opening up a window to do the double pumping on rising/falling pulse edges. They boost the clock and narrow the pulses, but if they go too far they lose the window for double pumping on those 7 cycles since it takes some amount of time to switch state to do the other operation, so they take it up as far as they can without losing the double pumping. Perhaps they feel bandwidth is more important than raw GPU power?
 
Last edited by a moderator:
Interesting thing to notice. :)

Maybe the eSRAM was found to double pump on 7 out of every 8 cycles due to the low latency opening up a window to do the double pumping on rising/falling pulse edges. They boost the clock and narrow the pulses, but if they go too far they lose the window for double pumping on those 7 cycles since it takes some amount of time to switch state to do the other operation, so they take it up as far as they can without losing the double pumping. Perhaps they feel bandwidth is more important than raw GPU power?

I would like to see someone with more experience on this then me comment, but it sounds like total rubbish to me. This wouldn't be something you suddenly realise near the end of your design, it would be something you realise early on imo.
 
The part where im pretty sure you have to start of by designing it like that and not just suddenly realise it over night.

You design all 8 cycles to double pump if that's your goal, sure. But this wasn't what we got here. If my theory on what happened is right, I don't see anything particularly shocking about it. Just good luck on MS's part. It could have very well been something that only popped up as they were finalizing their production testing.

For instance, you can get faster state changes in the transistors by making them smaller due to the way quantum tunneling works. Maybe they got the eSRAM smaller, more dense during some production test runs and didn't realize it was small enough to have the states be capable of switching so fast as to open the window on the pulse for double pumping? It's possible.
 
You design all 8 cycles to double pump if that's your goal, sure. But this wasn't what we got here. If my theory on what happened is right, I don't see anything particularly shocking about it. Just good luck on MS's part. It could have very well been something that only popped up as they were finalizing their production testing.

For instance, you can get faster state changes in the transistors by making them smaller due to the way quantum tunneling works. Maybe they got the eSRAM smaller, more dense during some production test runs and didn't realize it was small enough to have the states be capable of switching so fast as to open the window on the pulse for double pumping? It's possible.

I'm pretty sure you need to design it for double pumping from the start regardless of how much or little of it you want to do. There is no 'we will only do half double pumping therefore its going to work out of the blue'. Also eSRAM is a pretty mature design they wouldn't suddenly move it to a new process node, thats not really a smart move.
 
I'm pretty sure you need to design it for double pumping from the start regardless of how much or little of it you want to do. There is no 'we will only do half double pumping therefore its going to work out of the blue'.

Nah. So long as you can change the state of the transistors fast enough then depending on the pulse width you can have it read/write on both the rising/falling edges. Obviously you can design it that way at the beginning, but there are plausible scenarios where their manufacturing efforts gave them an opening they never designed. Given the fact we are talking about the production of an unprecedented 32MB of eSRAM here it wouldn't surprise me if they had to be conservative from the get go there (lest they risk totally shitting the bed on yields if anything goes awry).
 
Nah. So long as you can change the state of the transistors fast enough then depending on the pulse width you can have it read/write on both the rising/falling edges. Obviously you can design it that way at the beginning, but there are plausible scenarios where their manufacturing efforts gave them an opening they never designed. Given the fact we are talking about the production of an unprecedented 32MB of eSRAM here it wouldn't surprise me if they had to be conservative from the get go there (lest they risk totally shitting the bed on yields if anything goes awry).

So they designed it that way from the start, wasn't even on there presentation to developers nor mentioned anywhere at all until recently and now it suddenly works?. Sounds to like theres more to this then 'double pumping' and thats its something else that we are not seeing, maybe compression algorithms and they are talking in uncompressed terms.

Also if they really though bandwidth was more important then raw power they would have more CB/DB as even with the eSRAM update they are still limited to a 106GB/s write because of the ROPs.
 
So they designed it that way from the start...

No. They were conservative from the start and told devs what they knew they could pull off. The results from their manufacturing strides were enough to leave the window open for double pumping on 7/8 of the cycles.

Sounds to like theres more to this then 'double pumping' and thats its something else that we are not seeing, maybe compression algorithms and they are talking in uncompressed terms.

What do ya mean here?

Also if they really though bandwidth was more important then raw power they would have more CB/DB as even with the eSRAM update they are still limited to a 106GB/s write because of the ROPs.

Not if they didn't expect the eSRAM to be capable of double pumping on 7/8 of the cycles. They are taking advantage of good fortune there. Not sure how adding in more color/depth blocks comes about by means of blind luck like that.

That's true about the ROPs (though it is actually 109.2GB/s). Clearly they wouldn't do this if it wasn't showing real world payoffs though so I doubt the eSRAM efficiency boost is just being wasted, otherwise I see no reason to stop at 853MHz.
 
That's true about the ROPs (though it is actually 109.2GB/s). Clearly they wouldn't do this if it wasn't showing real world payoffs though so I doubt the eSRAM efficiency boost is just being wasted, otherwise I see no reason to stop at 853MHz.

Theres plenty of reason to stop at 853Mhz, you can't just arbitrarily increase a clock without a whole bunch of things changing and for the negative
 
Theres plenty of reason to stop at 853Mhz, you can't just arbitrarily increase a clock without a whole bunch of things changing and for the negative

The way the math seems to work out in light of the eSRAM info from DF (and what someone told me way back in May) sure seems to suggest it was anything but arbitrary. And the reasoning I've laid out accounts for what I feel is a pretty logical sequence of events.

The eSRAM efficiency boost happened in May. So that makes me wonder when this clock boost happened (remember my theory back in the day about why they didn't reveal their clocks as they weren't final yet? yeah...). If it happened in late May or even June then what's the deal with MS supposedly surveying devs about a clock boost or 12GB of RAM last month? Would that be a clock boost on top of the 53MHz, and thus kill the double pumped bandwidth?

If my theory on the boost/eSRAM is right then it's something MS would've done regardless as it doesn't hurt them at all, so why give devs the choice at all if this was the clock boost? And why tell devs the clock boost might be as much as 100MHz? I'm not sure how that alleged survey (if it actually was real to begin with) fits into my sequence of events.

I hope interference asks his dev source about if this is a result of that survey.
 
The part where im pretty sure you have to start of by designing it like that and not just suddenly realise it over night.

There is no way to know exactly what the thermal characteristics or power characteristics will be until you have final silicon. That's why companies rarely set a final clockspeed or voltage until they get final silicon back. If you've watched Nvidia and AMD over the years, this wouldn't seem odd as they wait until close to launch before setting final clocks and voltages with voltage being highly variable. Both GK104 and Tahiti, for example, have multiple voltage steppings depending on the quality of the chip.

Regards,
SB
 
cool astrograd is here, hey astro i lurk on txb mostly to read your posts you always break it down to make it understandable thanks man. you were saying on txb how this would put xbox over ps4 because ps4 can only use 12cus for rendering. i don't want to turn this into a versus, but with esram beign so fast wouldn't that by extnesion increase cu speeds in some way bringing them up to parity if not making them faster than ps4? also with the esram getting a bandwidth increase to like 210GB/s won't they need to increase the dme transfer speed too? i mean the gpu will be getting fed so much quicker from esram now.
 
I was also saying I heard 50 to 100 MHz upclock and nobody believed me!I also said I heard there was no downclock!i get no credit?
 
cool astrograd is here, hey astro i lurk on txb mostly to read your posts you always break it down to make it understandable thanks man. you were saying on txb how this would put xbox over ps4 because ps4 can only use 12cus for rendering.

I don't think anyone with an ounce of credibility would seriously believe that a 6% up-clock would put the Xbox One ahead of the PS4 in graphics performance.
 
cool astrograd is here, hey astro i lurk on txb mostly to read your posts you always break it down to make it understandable thanks man. you were saying on txb how this would put xbox over ps4 because ps4 can only use 12cus for rendering.

No, I was saying that it sounds like PS4 games will likely be utilizing only 14 CU's for rending based on Cerny's comments about them and whatnot and a comparison between 12 CU's vs 14 CU's is a completely different ballgame than the purported 50% performance advantage we were supposed to see in PS4 games. I didn't say it puts X1 ahead. PM me if ya wanna talk about that though.

also with the esram getting a bandwidth increase to like 210GB/s won't they need to increase the dme transfer speed too? i mean the gpu will be getting fed so much quicker from esram now.

The CU's operate per cycle, which is where you get the total GPU flops numbers from[(768 opcs/cycle)*(1 add + 1mult)*(853MHz)=1.31Tflops]. And DME's are based on the same timings as the eSRAM I think, so those should get the same boost. The eSRAM won't be netting you 210GB/s though. That's the peak theoretical value but in this context it seems (if my theory is right) that this value would never even come remotely close to being achieved. It'd be more like 142GB/s for the eSRAM instead.
 
I was also saying I heard 50 to 100 MHz upclock and nobody believed me!I also said I heard there was no downclock!i get no credit?

Yeah I couldn't recall your username when I name dropped interference earlier. ;)

So I ask you, was this the upclock MS was supposedly surveying devs about? I'm a bit confused on the timing of this stuff. When was the survey goin around? The 53MHz boost sounds like it was something MS got entirely for free, so why survey ppl asking about an upclock of up to 100MHz if they presumably knew beforehand that they got this for free? Good PR with devs or something to make them feel as if they were being listened to?
 
No, I was saying that it sounds like PS4 games will likely be utilizing only 14 CU's for rending based on Cerny's comments about them and whatnot and a comparison between 12 CU's vs 14 CU's is a completely different ballgame than the purported 50% performance advantage we were supposed to see in PS4 games. I didn't say it puts X1 ahead. PM me if ya wanna talk about that though.

sorry i got mixed up with your other post saying it would be xbox's 12cu vs ps4 12 cu because 2 would be used by the os and the other 4 are only good for compute gpgpu stuff. but if the other stuff you said about the display planes helping xbox one games hit 60fps easily when compared ps4 games, and esram bandwidth increase + what you said about the xbox one cpu having more bandwdith than ps4 cpu (40gb compared to 20gb/s) i assumed it meant xbox would be ahead. I'll send you pm, i always want to learn more. i will admit im confused a bit now since youve clarified.


The CU's operate per cycle, which is where you get the total GPU flops numbers from[(768 opcs/cycle)*(1 add + 1mult)*(853MHz)=1.31Tflops]. And DME's are based on the same timings as the eSRAM I think, so those should get the same boost. The eSRAM won't be netting you 210GB/s though. That's the peak theoretical value but in this context it seems (if my theory is right) that this value would never even come remotely close to being achieved. It'd be more like 142GB/s for the eSRAM instead.

cool and the gpu sees that as one big pool so it's really 210gb/s? man ms engineers are amazing. all these tech upgrades + its being more efficiecnt because of the dmes and whatnot makes xbox sound just ridiculously powerful. proof is in the pudding ryse is pretty much the most amazing thing i saw at e3.

some time ago you suspected that the display plane will allow fore more games to be 1080p and 60fps is that the limit to the display planes or can it do say 4k gaming? i remember ms saying that xbox one was capable of it, would it be wrong to credit the display planes for that?
 
Status
Not open for further replies.
Back
Top