The ESRAM in Durango as a possible performance aid

So with deferred rendering being so popular now, how does a choice to go with 32MB of ESRAM affect games, even though ESRAM's bandwidth is lower than the 360 EDRAM's bandwidth, or does this not matter as much since you could only use all that bandwidth on the 360's EDRAM under certain circumstances?

Not sure if that's the right question, but I assume there are some advantages to ESRAM.
 
So with deferred rendering being so popular now, how does a choice to go with 32MB of ESRAM affect games, even though ESRAM's bandwidth is lower than the 360 EDRAM's bandwidth, or does this not matter as much since you could only use all that bandwidth on the 360's EDRAM under certain circumstances?

Not sure if that's the right question, but I assume there are some advantages to ESRAM.

ESRAM to GPU bandwidth is significantly higher than X360's eDRAM to GPU bandwidth.

Regards,
SB
 
Oh, so meaning that the gigantic bandwidth figure on the 360's EDRAM was simply just its internal bandwidth, but not the bandwidth speed it would use to read and write information to the GPU?

I assume then that you're referring to the 32GB/s shown to in this picture.

X360bandwidthdiagram.jpg


Does it make sense at all that developers could pass most kinds of graphics data into the ESRAM from main memory using one or more of the move engines, and then have the GPU read and process the data inside ESRAM, and then as, or potentially even before further relevant data connected to the existing information still in ESRAM is needed, again use the move engines to bring new data inside ESRAM fast enough before it's ever actually needed, likely removing the no longer needed data also? Probably a rough explanation, but does that seem like a process in which a developer could continually repeat over and over with enough reliability as necessary for specific data while still meeting all the other performance needs of their game?

Given what their game is doing, is it conceivable that in about 10-15 minutes worth of gameplay time, a developer could have shuffled potentially 128MB worth of unique data in and out of the ESRAM's available 32MB storage in a way that helps their game a great deal? Or would this kind of stuff have to be very limited to certain tasks, as opposed to a jack of all trades piece of fast memory that you can use however you please if you design and plan properly for it?
 
Up to this point, everyone has used eDRAM for very large local stores. MS's choice is definitely something new. However, if you want to have flexibility in where you produce your chip, you can't be reliant on eDRAM. It's a very interesting choice by MS that'll stir up discussion for years I reckon, like Sony's choice of Cell.
 
Up to this point, everyone has used eDRAM for very large local stores. MS's choice is definitely something new. However, if you want to have flexibility in where you produce your chip, you can't be reliant on eDRAM.

Exactly. It's worth noting that Intel's eDRAM is on a separate die made with a different process than their logic process. You bet Intel would integrate it into the CPU if they could.

The lifetime for XB1 is going to be close to a decade. Let's say MS had mimicked Intel and put 128MB eDRAM on there. In five years time they'd be prevented from shrinking it further because of pad limitations.

Cheers
 
A fully optimized g-buffer layout (Crytek 3), uses 12 bytes per pixel. On 720p that is 10.8 MB.

So thats 23.73MiB for 1080p target. Someone has bytes per pixel (Bpp) of other engines to compare the needs of advanced techniques will fit in the ESRAM.

IIRC, some rumours stated that 32MiB is too small for 1080p with AA.
 
Last edited by a moderator:
the esram isn't even necessarily targeted at framebuffer though, according to ms themselves. so it may be somewhat moot this time. you put the framebuffer in ddr3.
 

OK, so in the rumours of Halo5 the Game-Plane uses 1920x720 and the Ui-plane uses 1920x1080p. Deferred Shading with G-buffer spaning 4MRTs, everything HDR in linear space. How much space in the ESRAM?

http://forums.halofollower.com/index.php?/topic/323-halo-5-possible-leaked-info-details/


If render targets are in DDR3. ESRAM is used for alpha blending and other bandwidth starved techniques, then ESRAM targets will be tiled ? Another thing is triple-buffering will use ESRAM? if not smooth framerates and tearing will battle each other again?
 
Another thing is triple-buffering will use ESRAM? if not smooth framerates and tearing will battle each other again?
There is no advantage of storing front buffers in ESRAM, so no.
Tearing and usage of a vsync is up to developer, it's seriously a fix of couple lines.
 
That intel didn't want to waste billions of transistors on esram and that it isn't that easy to do hence Xbone's bad yield rumours.
SRAM is easier than eDRAM ... and because of the trivial redundancy it won't impact yield either.

Intel used DRAM because it's cheaper and their process and integration technology is more advanced.
 
The lifetime for XB1 is going to be close to a decade. Let's say MS had mimicked Intel and put 128MB eDRAM on there. In five years time they'd be prevented from shrinking it further because of pad limitations.
The number of pins AMD would need for it's current bandwidth is tiny ... with area IO they could fit in order(s) of magnitude more pins than necessary in 5 years.
 
Well yeah, that's what they could fit in ... what they would need at current bandwidth is a couple hundred of each (system clock doesn't need to be used for the interface, you can just use a multiple ala DDR/QDR).
 
Back
Top