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

I was thinking it has to behave exactly the same, so they would simulated the exact DDR3 timings by adding delays. They can't allow new slim model to run games faster, the game would have to be tested for two hardware, studios would be angry, early adopters would be angry.

2 things come to mind. One is isn't the game code only interacting with the GameOS virtual machine ? As long as the VM acts the same would it matter how fast the hardware was ? Not knowing the answer the next thing that comes to mind would be ESRAM specific routines that might be affected by major changes in the memory system.
 
Most universities don't even teach performance critical programming, unless you take some special courses (and there aren't many available). Nowadays C/C++ isn't even that commonly used language in schools/universities anymore. Writing cache efficient code in Java (or many other currently popular languages) is very hard, since you can't control the placement of the objects in memory (and long pointer chains are very frequent). The common thinking is that low level optimization is the responsibility of the compiler. Unfortunately compilers aren't good in optimizing memory access patterns.

Really? this is interesting, I have taken 5 classes so far that cover c/c++ and two have covered caching/pipelining etc and only one was specifically a HPC course. 3 of them are mandatory as well.
 
I was thinking it has to behave exactly the same, so they would simulated the exact DDR3 timings by adding delays. They can't allow new slim model to run games faster, the game would have to be tested for two hardware, studios would be angry, early adopters would be angry.
I'm not sure that's true. By then the XB1 will be old. It's not different to a mobile upgrade, except far, far less pronounced. It could also spur early adopters to buy new hardware for the mildly better experience (something they often do already when the slim model comes out). As long as it doesn't break the games, it's an option to replace the ESRAM.
 
If you mean replacing the ESRAM with HBM or some other external DRAM standard, that might be a thornier problem.
At least going by other on-die storage schemes, the ESRAM is going to favor a different access mix relative to an external DRAM standard, since it has a bidirectional interface and shouldn't have the physical constraints that create such large bus and device turnaround latencies in DRAM.

A well-mixed read/write access pattern the ESRAM has no problem with could cause an order of magnitude drop in DRAM performance.

Perhaps once HBM is out in the wild and profiled, we can discern how differently it behaves relative to the current standards. I'm not certain it can change the different performance profile on-die memory has relative to a device that still has a (admittedly shorter and wider than before) off-die bus.
 
Sorry, I didn't want to suggest HBM would definitely be a suitable replacement. I'm not tech savvy enough to know such things. I just think that games these days are removed enough from the hardware that an alternative memory wouldn't break the software as the games would still see it pretty much the same. They'd issue their memory requests and be served accordingly.
 
Memory is memory, it doesn't really matter where it's being used, so there's no need to take the [PR] statement way out of context.
 
57915657542283503584.jpg
 
This was discussed earlier.
The architects indicated that the memory controllers and ESRAM controllers sit on the other side of a crossbar, which makes accesses mostly interchangable after memory is mapped.
 
I'm a bit more curious about their renderer setup considering it's UE4, which by default has a pretty fat G-buffer. They've clearly made some big changes with LPV GI & the general "look" of the game though, and so far, they haven't exactly shown off lots of dynamic lights either...
 
Let us take a scenario where you have 20 different render targets per frame and you render them into memory, it will be hard to say this will be faster than this one and it’s even hard to make a general assumption about something, especially with the eSRAM in the mix. It highly depends on how you use system memory and eSRAM. You will run a lot of performance captures to see what the bottleneck is, memory access or arithmetic instructions. In most cases I predict memory access patterns will be your biggest challenge

http://gamingbolt.com/gpu-rops-diff...lect-practical-scenarios-esram-still-a-factor
 
plz move* sorry long story but wrong thread

I'm curious if anyone out there thinks if the esram peak was still only 109GB/s what impact that might have on some of the games currently released. Though I suspect for many of the games already released if it was only 109 it wouldn't impact IQ or fps too much.
 
Last edited by a moderator:
I'm curious if anyone out there thinks if the esram peak was still only 109GB/s what impact that might have on some of the games currently released. Though I suspect for many of the games already released if it was only 109 it wouldn't impact IQ or fps too much.
That is when only writing to it or just reading from it. It can do both at the same time for most of the time, theoretically 7/8ths of the time. Once developers map their data accesses to take advantage of that efficiency you will see some fine performance. Whether or not it's 1080p/60fps is another story and whether or not that level of performance is an issue is yet another story.
 
plz move* sorry long story but wrong thread

I'm curious if anyone out there thinks if the esram peak was still only 109GB/s what impact that might have on some of the games currently released. Though I suspect for many of the games already released if it was only 109 it wouldn't impact IQ or fps too much.

Is it possible that 1st and 2nd wave of games were given this number (pre 2013) and many games built around it? Impossible to prove or disprove though. I would think the number wouldn't matter for developers, they'd do whatever it takes to get things working, with the caveat of not breaking what they already made.
 
Is it possible that 1st and 2nd wave of games were given this number (pre 2013) and many games built around it? Impossible to prove or disprove though. I would think the number wouldn't matter for developers, they'd do whatever it takes to get things working, with the caveat of not breaking what they already made.

This is probably the number they were given, IIRC in the Eurogamer article on the ESRAM 'bump' they noted that it was only with final silicon they were able to properly profile the peak bandwidth available. Of course others with more expertise than me have looked askance at that explanation but if we take them at face value then yes at least the first wave of games will have been designed with the 109GB/s number in mind. That being said I haven't seen too many devs point to what it is about ESRAM (or the GPU) that might be the bottleneck there has been speculation it's the capacity, bandwidth or a combination but in truth it more probably depends on the particular s/w design.

TL;DR Probably but we don't know what specific aspect of ESRAM is responsible for any performance drop vs. PS4 or if ESRAM has anything to do with it all (instead of say DDR3 or the lower SPU count).
 
Is it possible that 1st and 2nd wave of games were given this number (pre 2013) and many games built around it?
Not only possible, but provable! VGLeaks documentation was a leak of the developer documentation given to developers. Everything in VGLeaks is exactly what devs were told. 104.2 GB/s (it got upclocked).
 
Not only possible, but provable!
^^^
LOL. I'm not sure why I've been chuckling at your comments lately, but you are on a roll.

Shocking amount of information they have on that site on the insides of the X1 pre-release as well. I'm left to wonder which launch titles made full use of DDR3 and little use of ESRAM now. Not that it matters, but I'm very curious to know how inflexible some renderers are, or if the time constraint to figure out all of that is just too much. Likely the latter, as MJP said in another thread, why throw away good code?

I'm inclined to agree with him. Wow that's crazy disparity though. PS4 was a solid launch in that regard.
 
The ESRAM isn't that inflexible, and the first two phases default in the most probable heavy bandwidth consumers, which means decent utilization is at least likely.
Making little use of it would mean trying to run a little below the PS4 on ~70GB of memory bandwidth for demanding titles. It's not that bad.
 
The ESRAM isn't that inflexible, and the first two phases default in the most probable heavy bandwidth consumers, which means decent utilization is at least likely.
Making little use of it would mean trying to run a little below the PS4 on ~70GB of memory bandwidth for demanding titles. It's not that bad.

~70GB of bandwidth sounds bad, are you saying it isn't?

Also, in your view, how much ESRAM would have been 'enough'? (i.e. where swapping render targets wouldn't be necessary and first gen titles wouldn't have suffered so much?)
 
Back
Top