esram astrophysics *spin-off*

[shredenvain]

I don't think this is the right topic to go further down this line... I'll say this much... the driver support for my mainboard dried up right after I bought it (I am not making Microsoft responsible for it).

So... ESRAM. I am still wondering as to why MS first had just 102 and now has ~twice that. I mean, they should now what they were designing. And by the time they were getting ready to announce their hardware, they should've also known if it works or not... Seems too strange to me, sort of.

I remember ms saying in the df interview they went with esram because edram wasnt going to be available from the company building the chips. They also said the sram bandwidth quoted in the vgleaks documents was from early development documentation which was obtained from running simulations of the apu. Once they got the actual chips back they realized they underestimated the bandwidth. Maybe they made miscalculations when they ran the simulations. Maybe they didnt take into acount the possibility of doing simultanious read/writes. The 200+gbs seems plausible with it having a total bus width of 1024 bit and being divided into multiple sections.

 

[TheWretched]

I am not saying it's not possible. I am merely thinking the way it was announced was fishy. Assuming the leaks were false (which is likely) then they wouldn't have needed to make a big deal out of it... but since MS made a big deal out of everything they did with hardware, lately, it's kind of a given that they'd announce it this way, too.

 

[Shifty Geezer]

T'was covered with the DF interview of the XB1 architects way earlier in this thread:

"When we started, we wrote a spec," explains Nick Baker. "Before we really went into any implementation details, we had to give developers something to plan around before we had the silicon, before we even had it running in simulation before tape-out, and said that the minimum bandwidth we want from the ESRAM is 102GB/s. That became 109GB/s [with the GPU speed increase]. In the end, once you get into implementing this, the logic turned out that you could go much higher."

"There are four 8MB lanes, but it's not a contiguous 8MB chunk of memory within each of those lanes. Each lane, that 8MB is broken down into eight modules. This should address whether you can really have read and write bandwidth in memory simultaneously," says Baker.

"Yes you can - there are actually a lot more individual blocks that comprise the whole ESRAM so you can talk to those in parallel. Of course if you're hitting the same area over and over and over again, you don't get to spread out your bandwidth and so that's one of the reasons why in real testing you get 140-150GB/s rather than the peak 204GB/s... it's not just four chunks of 8MB memory. It's a lot more complicated than that and depending on how the pattern you get to use those simultaneously. That's what lets you do read and writes simultaneously. You do get to add the read and write bandwidth as well adding the read and write bandwidth on to the main memory. That's just one of the misconceptions we wanted to clean up."

Goossens lays down the bottom line:

"If you're only doing a read you're capped at 109GB/s, if you're only doing a write you're capped at 109GB/s," he says. "To get over that you need to have a mix of the reads and the writes but when you are going to look at the things that are typically in the ESRAM, such as your render targets and your depth buffers, intrinsically they have a lot of read-modified writes going on in the blends and the depth buffer updates. Those are the natural things to stick in the ESRAM and the natural things to take advantage of the concurrent read/writes."

 

[taisui]

oh god, don't tell me this gets recycled once again...

I like a world where officially announced data are deemed fishy
...and at the same time some are trying so hard to hint that something is actually faster than it is while it's not. *wink

 

[Arwin]

oh god, don't tell me this gets recycled once again...

I like a world where officially announced data are deemed fishy
...and at the same time some are trying so hard to hint that something is actually faster than it is while it's not. *wink

Get used to it. New people get interested in the same topic all the time. This will happen occasionally over the rest of the new console generation, and possibly even beyond.

 

[TheWretched]

I guess taisuis post was regarding my post... Don't misunderstand my meaning. I am not saying the "content" is fishy, just the way it was announced. Making a mountain out of a molehill situation of sorts. Because if MS new all along that they were designing a "DDR"ish ESRAM, then having it work is supposed to happen, not a happy accident, which the Eurogamer article makes it sound like.

 

[Shifty Geezer]

I am not saying the "content" is fishy, just the way it was announced.

It was announced as a rumour from internal documents. These can't be 'fishy' as there's no context nor appreciation of the intended audience, nor understanding of who provided the source material and what technical know-how they had to interpret it and explain it effectively, nor scope to explore interpretation of the source. The initial rumour is completely irrelevant now - we know exactly how it works.

 

[Shifty Geezer]

What's still interesssting about the esram is its bandwidth. The 109-204 GB/s are just for the tiny 32 MB space. If you try the same with GDDR5 memory, you wouldn't get this high bandwidth for a tiny fragment of the memory. So this is really really fast, tiny but fast. But what can be done with it. It should be more than enough for a 1080p render target but the large things (textures etc) must come from DDR3 memory.

There's a discussion on scratchpad memories here:

The pros and cons of eDRAM/ESRAM in next-gen

This thread should probably be closed as the mystery of the eSRAM has been solved.

 

[AlNom]

Quite right.