Part Two of the Tech Talk series. And this time we are talking about ESRAM!!!
First.. what is eSRAM?
This stands for Static memory. And the "e" means its embedded on the processor die. Pretty straight forward. It has an effective total bandwidth of 102GB/s. You see, there are 3 bandwidth pools in the XB1 that works independently of eachother. System ram@68GB/s. ESRAM@102Gb/s and lastly; the data move engines (DME) which has 30GB/s and is designed to move data from GPU (more specifically the eSRAM) to and from system memory without any computational hit. Pretty ingenious actually.............................(Edit 1)
The nitty gritty
eSRAM (in the XB1) is 32MB in size. This is very very very very important to remember. So while it has a ridiculous amount of bandwidth, it doesn't have a lot of it. This doesn't just limit what it can be used for, but also how it can be used. If used effectively, it would be primarily used as a cache. Using it this way would boost the XB1s memory performance to near PS4 levels. Albeit some concessions still have to be made. Let me explain.
As a cache, GPU assets that are read/written to frequently (a lot) would be stored on the eSRAM. This is because if the GPU has to read from the slower DDR3 memory instead it would slow the render pipeline down and ultimately stall the XB1. So using it to cache data that the GPU accesses often prevents the GPU from waiting for data to work on and/or where to keep said data. If done right, it could match the PS4s memory bandwidth performance. Problem is however, you can only store so much on the ESRAM. 32MB. Lets get a little technical..
All 3D rendering hardware needs at least three bitmaps stored on memory. These are called the
- Back-buffer [B-buffer] - where the GPU drawa the current frame
- Front buffer [F-buffer] - which is where the last drawn B-buffer is stored and then sent to your screen for you to see
- Z buffer - which is a map of the depth of every pixel and which makes it possible for the GPU to easily draw traingles as needed, render targets go here too.
Think of a buffer as a picture. A 20mpx picture has more data than a 5mpx picture. A 1080p HDR Back buffer takes up ~16MB of memory. Then the Z buffer takes up another 8MB. All you have left is 8MB. And you have not even added other more complex post processing effects (AA, bokeh...etc) to the B-buffer which would make it even larger. And the scary thing about some of these post processing efects is that something like 2x MSAA (hence why FXAA is so pupular) will literally bumb the b-buffer size by around 70%!!!!!!!! Make no mistake, the ESRAM exists solely to host the back buffer and z-buffer. But this is an easy problem to fix. If you are microsoft that is and you shit rainbows.
It just so happens that they do..... kinda.....
[Just get it out there Lazy dev Go To Solution]Just drop the resolution. Lower resolution, smaller sized back buffer, smaller sized back buffer less eSRAM being used. Win win. Some devs take it a step further and even cull some stuff from the z-buffer (thats why you may see some PS4 games having geometry assets that seem to be missing on the XB1). Ths gives you more room to do all the post processing stuff that gets aded t every frame. Stuff like that just can't exist anywhere else but on the ESRAM.
Poor ESRAM, it gets blamed for everything pixels are bad too!!
A common misconception is that the resolutiongate (720p vs 900p vs 1080p)is irrelevant and minuscule. Truth is that poeple couldnt be more wrong, especially when considering the hardware impact of resolution and its memory footprint. Remember, a buffer is an image. That image is made up of pixels. The GPU "draws" these pixels. A picture's resolution is practically the building block of that picture. But lets put it to rest, When someone says 900p vs 1080p. Its easy to look at that and just go "herp derp u'all bitching over 180p!!!! hahahahahah". If you have ever done something like that before, slap yourself now and call yourself stupid. Numbers time!!
- 900p = 1600 x 900 = 1, 440,000 pixels.
- 1080p = 1920 x 1080 = 2, 073, 600 pixels
- that is a difference of 600,000 pixels!!!!!!!!!!! NOT just a 180 pixel difference lol.
- 900p is ~40% less than 1080p
Its not all doom and gloom (aka. we know how to optimize "unlazyy dev appraoch")
Remmeber when I said MS kinda shits rainbows? Well, I realy meant it. Cause that is the only way they could pull this off. Which they did by the way.
Microsoft is a software company. And not just any software company, they are the guys that created the DX shader language. These guys know their shit. So, first off, they were smart enough to put in ESRAM to begin with. They would have gone for more but then the APU die would have been too big and harder to manufacture. But hey, at least they put it in. Only if they could have squuezed in 128MB.. or even 64MB, then all the resolution crap would be non existent. Ah well....
What MS did, or at least they are hoping developers will do, is something called Tiling.
Contrary to how it sounds, tiling doesn't mean you stack images on images and can thus cram more into ESRAM. Nope, it just means that you can break up images or components of your render pipeline so that way you can do more with the little ESRAM you have. Let me explain. say you have a racing game. And the sky, top half of your screen is alway going to blue, Or better yet, a particular image/skybox. What tiling lets you do is;
- to render just that portion of the sky on the b-buffer once
- Cut it off and send it using the DME to DDR3 memory
- then access it from theer since it doesn't need to be refreshed or re-rendered every single time. Brilliant.
The problem is that the tiling thingy wasn't ready at the start of the current gen. And even now devs are really just beginning to wrap their heads around it cause the SDK really has to be on point to allow devs access parts of an image in sync from two different pools of memory. Trust me.... its no easy feat and its a small miracle that MS could pull it off.
And contrary to what some may say... ESRAM has nothing to do with a games framerate. Well kinda. This is because what are mostly in ESRAM are caches, and they are flushed once used. So there is nothing to stall the pipeline. ESRAM is there to save the framerate. Cause without it the GPU will spend too much time making simple render calls.
Conclusion
So its not all that bad. And truth be told is that if anyone could pull of the kinda software magic it requires to get ESRAM to shuffle and manage as much data as it need to to keep up with a modern day HD game with all effects turned on... it had to be microsoft. Was ESRAM a bad idea? Yes it was, but a necesary evil though cause MS had to go with a minimum of 8Gb or memory. And at the time 8GB of GDDR5 did not exist. Its still nowhere near as bad as the cell processor debacle though. Will we one day see every XB1 game also running at the same resolution with its PS4 counterpart? Yes we will. There will still be an IQ advantage for the PS4 though but they would at least both be running at the same resolution at some point. Well..... at leaast with a lot of games.
edit 1 (adjusted some numbers and removed some talk about microsoft math) (Thanks kreshnik for clearing up some info)
edit 2 (proof read and corrected errors/typos and rearranged content to make it easier to read) (thanks Binary for the suggestion)
