esram astrophysics *spin-off*

Status
Not open for further replies.
Some really interesting tidbits from this excellent article:

http://www.extremetech.com/gaming/1...d-odd-soc-architecture-confirmed-by-Microsoft

I didn't know the eSRAM has been broken into four 8MB chunks. I wonder what are the implications of this. 8MB is just a very small amount of memory in order to fit a full 1080p framebuffer, isn't it? :eek:

It's probably just how it's laid out in the design. It's probably 4 8MB banks, but still looks like a unified 32MB memory.
 
Some really interesting tidbits from this excellent article:

http://www.extremetech.com/gaming/1...d-odd-soc-architecture-confirmed-by-Microsoft

I didn't know the eSRAM has been broken into four 8MB chunks. I wonder what are the implications of this. 8MB is just a very small amount of memory in order to fit a full 1080p framebuffer, isn't it? :eek:

So it's not a solid 32MB chunk as/was expected ...so, latency and sync issues will have to be handled/addressed between the four (4) 8MB blocks at some level. Looking at the diagram, it seems the eSRAM is strictly cache for the GPU and CPU, and nothing else. Something about this setup screams headache in once sense, and unique "if the results" are worth the headache. Only time will tell....

It's probably just how it's laid out in the design. It's probably 4 8MB banks, but still looks like a unified 32MB memory.

No. It looks like four (4) individual 8MB blocks to me, each with separate channels.
 
So it's not a solid 32MB chunk as/was expected ...so, latency and sync issues will have to be handled/addressed between the four (4) 8MB blocks at some level. Looking at the diagram, it seems the eSRAM is strictly cache for the GPU and CPU, and nothing else. Something about this setup screams headache in once sense, and unique "if the results" are worth the headache. Only time will tell....

No. It looks like four (4) individual 8MB blocks to me, each with separate channels.

So then you're also going to say that the main DDR memory is really four (4) individual 2GB blocks, each with separate channels? How on earth will any developer ever be able to fit more than 2GB of memory in that layout? ;)
 
The whole magic esram-numbers can be explained through the following:

Imagine a USB drive, which has a transfer rate of 10MB/sec in both directions.
You send a 100MB word document, which takes 10 seconds.
Now you send the same 100MB word document, but it's a zipped version, totalling 70MB. The transfer takes 7 seconds.

Now, we have MS-PR thinking.. "a 100MB word document got transferred in 7 seconds", so this translates into:
"we proudly discovered that our USB drive has not a 10.0 MB/sec transfer rate, but in fact, a 14.28MB/sec transfer rate. :love:

So if they are going to claim 133MB/sec transfer rates in "special scenarios", or whatever PR-magic sauce they came up with, they should claim that the 32MB buffer is 23MB under special scenarios as well. :rolleyes:

Not that it matters, the general consensus amongst 360-fans is that Microsoft has some secret magic hardware and that a 50% to 300% difference (depending on wether we are looking at ROP count, compute units or memory bandwidth) won't produce any noticeable realtime difference in multiplatform games . Or a magic SHAPE audio chip which in reality is just a mere 10gigaflop component will even the playing field :LOL:
 
Compression modules are behind the southern bridge. Data is being pushed to ESRAM through the GPU-bound memory controller which is detached from southern bridge. So no, data in ESRAM is not compressed. You're also missing the fact that there's *more* on-chip buffers than we can add known buffers to, not *less* so it'd be about bloat, not compression.
 
So then you're also going to say that the main DDR memory is really four (4) individual 2GB blocks, each with separate channels? How on earth will any developer ever be able to fit more than 2GB of memory in that layout? ;)

Why the sarcasm? I thought moderators were suppose to be helpful, not antagonistic. Anyhow, I interpreted the diagram as having four (4) 8MB modules of eSRAM. Also, wondering (out loud) how latency would be handled between these individual modules - in relation to the other components (CPU and GPU) within the system.
 
Well I guess it comes town to repeating ad nauseum parts of a poorly worded article, if not an article that denotes some missunderstanding of the tech overall.

If you go by the same line, the 2MB of L2 cache in a Jaguar compute cluster as in Kabini is organized in four banks of 512KB iirc. I guess it is the same in a lot silicon designs.
 
You used the number from DF to form the hypothesis and the number from today to validate it? That is some circular logic.

I was told back in May that the eSRAM's bandwidth was significantly higher than what everyone thought and whe I pressed my source was told it was somehow due to the timings. I was also told that typical real world usage was around 133GB/s (back in May before clock boost) for the eSRAM and the peak value was a fair amount higher than 166GB/s.

MS was telling devs this info (192GB/s peak, 133GB/s real world) back in May according to DF. Most ppl somehow convinced themselves that because they personally couldn't reason through how that boost in bandwidth might be possible, therefore it had to be impossible. Ppl here and elsewhere assumed DF had completely fabricated that figure, or that the figure had been leaked that figure by MS's PR team, or that someone engineering the hardware was too dumb to adequately do their job and somehow was telling devs a bunch of wrong info.

As I told Shifty, HotChips verified what the DF article was claiming to a tee. Not only on a superficial 'higher than everyone assumed' level but down to the precise mathematics of it.

Should we be surprised? No, the initial info came from MS. But we can now ignore anyone claiming it was some ignorant mistake on MS's part (unless you wanna call the presenters at HotChips fools, in which case why are you bothering taking anything they say seriously?). We can rule out assertion of the hivemind at GAF telling us it was all made up out of thin air by DF who evidently is seen as a wholly owned subsidiary of MS all the sudden (HA!). We can also rule out the notion it was a PR stunt (MS would have been better served to reveal this info at HotChips instead of it leaking early).



Rockster said:
The 109 min to 204 peak is far from explained. If it were as simple as a 7/8 clock penalty, I think they would say that. Still feel there are for more esoteric requirements to exceed 109GB/sec.

Why would you presume they would say anything about something so technical as the 7/8 notion? They only have 30mins for the whole talk and some amount of that has to tackle the Kinect stuff too. Don't really see why they would want to dive into the nuances of how they got their figure there on one small part of the design pertaining to one aspect of the architecture.

It'd be fantastic if maybe DF could try snagging an interview with someone like Jeff Henshaw maybe and asking about that particular calculation. Not only is it pretty important for establishing technical capabilities of the console graphically it is also likely to make for an interesting tale about a hitherto unforeseen benefit of the manufacturing processes or whatever it was.
 
No one ever said DF made it up, they said DF was regurgitating what MS told them. So we are back to a single source, one does not back the other up. We still have no idea where the numbers came from or how real they are.

Saying one number is 7/8 of the other is not an explanation, it is math. I want to know where the 204GB/s number comes from and what it takes to break the "min" number which used to also be the max.
 
No one ever said DF made it up, they said DF was regurgitating what MS told them. So we are back to a single source, one does not back the other up. We still have no idea where the numbers came from or how real they are.

Saying one number is 7/8 of the other is not an explanation, it is math. I want to know where the 204GB/s number comes from and what it takes to break the "min" number which used to also be the max.

How many sources do you need other than the one from the horse's mouth? What? Are console manufacturers suppose to submit their hardware for independent verification of the official metrics they provide to make forum goers happy?
 
How many sources do you need other than the one from the horse's mouth? What? Are console manufacturers suppose to submit their hardware for independent verification of the official metrics they provide to make forum goers happy?

I wasn't asking for sources, I was asking for technical details. The info has always came from MS, there was no doubt in my mind.
 
If Sony were to counter this information with a claim that they have found a way to boost the PS4's bandwidth to 300GB/s would you just take that claim at face value? You've got to admit that under the circumstances microsofts claim is fishy. I'm not saying its a flat out lie. But creativity with the truth to make their consoles seem more powerful than they actually are isn't exactly unprecidented for either vendor. The 1 TFLOP xbox 360 is testament to that. If we didn't get the low level detail of the shader setup in the 360 we might have gone on merrily believing that it packed a terraflop of shader power. I see no difference here. People want to understand the detail to understand how honest microsoft are being.
 
If Sony were to counter this information with a claim that they have found a way to boost the PS4's bandwidth to 300GB/s would you just take that claim at face value? You've got to admit that under the circumstances microsofts claim is fishy. I'm not saying its a flat out lie. But creativity with the truth to make their consoles seem more powerful than they actually are isn't exactly unprecidented for either vendor. The 1 TFLOP xbox 360 is testament to that. If we didn't get the low level detail of the shader setup in the 360 we might have gone on merrily believing that it packed a terraflop of shader power. I see no difference here. People want to understand the detail to understand how honest microsoft are being.

If Sony was running around with some exotic version of gddr, I would have no problem with their claim.

MS for the most part is a toddler when it comes to hardware design. And they have been a heavy advocate of implementing fpgas in asic design. But designing something on a fpga doesnt mean you get 100% conversion when moving a design from a fpga to a asic. Some fpga's i/o and ram features cant be readily replicate in an asic design. Sometimes you have to add extra logic to accommodate the conversion.

MS isnt AMD or IBM. The logic on eSRAM is more than likely someone's else IP. Being surprised by a design with a bunch of other companies IP shouldnt be that impossible. From my count there are at least 3 different companies not named MS whose IPs is in durango. Given the complexiblity and features you dont readily see on an AMD apu, I wouldnt be surprised if there are more including third party ips surrounding esram and the dmes.
 
If Sony made that claim everyone would be right to ask, "how is that achieved?" If Sony refused to offer any explanation people would be right to be suspicious. That's what's happening here. We have a lot of people repeating a claim, but no one seems to have any explanation for how it works. Even Astrograd's theory boils down to a handwaving "quantum mechanics did it!" like he's writing the third act of an episode of Star Trek.
 
If Sony made that claim everyone would be right to ask, "how is that achieved?"
And w/o a very, very deep knowledge of the RTL you wouldn't be able to verify their claim. So what's the point? Memory controllers are weird beasts. Whenever I hit something around the MC in our HW I just ask people ten times smarter than me to take a look at it. There are dragons to be found there and very few people are brave enough to fight them. :LOL:
 
And w/o a very, very deep knowledge of the RTL you wouldn't be able to verify their claim. So what's the point? Memory controllers are weird beasts. Whenever I hit something around the MC in our HW I just ask people ten times smarter than me to take a look at it. There are dragons to be found there and very few people are brave enough to fight them. :LOL:

Problem is we're still trying to figure out how they suddenly can pump 1920 bits per cycle through a 1024 bit bus in certain conditions, and the reasoning behind why it's so conditional, such that you, in reality, get the claimed 133GB/s and not the full ~204 GB/s on average.

It's the "huh? what the?" part that gets the skepticism high, if we have a through explanation on how it's done and if it looks sound, I think most people here would be more than happy to accept it.
 
We all know the nature of the mystery. Whether MS are using creative PR or not is a matter of faith at this point. Can we please keep this thread to possible technical solutions to the mystery.

Why would you presume they would say anything about something so technical as the 7/8 notion?
Because it's potential a complete revolution within the EE sector!! Seriously, they've come up with a BW enhancing feature that no-one can fathom, and they didn't talk about it at all? "Hi guys, welcome to HotChips. Today we'll be talking about games console APU, which is much like any other AMD APU. One special feature we have is that we've found a way to get partial double transfers across a bus boosting bandwidth by 30% or more. I see you're all pretty excited at that prospect! But we won't talk about that. Instead we're going to discuss some conventional specialist processing blocks in there." :p They didn't present any interesting tech at HotChips, neither their ToF sensor nor how they have achieved something no-one else has achieved for boosting IO BW. I think a lot of us presumed MS would show something more interesting. I don't honestly know why they bothered showing what they did because it doesn't reflect anything of interest within the EE sector. They kept out all the juicy bits.
 
Status
Not open for further replies.
Back
Top