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

[SlimJim]

Not sure if serious. Engineers develop for the hardware, they take into account its setup and architecture.

Going into this launch year all rendering engines for consoles mainly became deferred. Fitting multiple 32bit g buffers into 32mb is the problem, so you will need to use overspill or other methods to make this work.

Granted as long as deferred, tiled deferred and other deferred methods in the future hold king then 

If Xbox One would become lead platform (meaning that games are developed to it's strength, and then ported to PS4) then they would use those other methods.
It's like you say only a problem if they try to fit a 'next-generation' engine derived game into the buffer without giving it much thought.

edit: with PS3 sony apparently had the Ice team help up multiplatform developers in some cases, in order for the game to run well on PS3. Maybe Microsoft can do something similar?

 

[iroboto]

Eh. Id say it takes time. Lead platform might help accelerate first party: but as many developers will tell you, why throw away good code ?

 

[3dcgi]

Thanks.

I got it into my head that modern compression could use a smaller buffer, depending on level of compression a particular buffer was suitable for, and that while you'd always need to have the full uncompressed size available you could make do with less space in most cases. The idea here was that you could put the most commonly used portion in esram and put the "overspill" component in main ram.

Perhaps you could sort-of achieve this by doing a Z pre pass, then (lossless) compressing depth down using compute? This would reduce the memory footprint of the depth buffer in esram, and in worst cases that didn't compress well you could overspill in main ram, leaving more esram for other buffers?

... or perhaps that would be too expensive. *shrugs*

I believe developers have enough detail about how Xbox's compression works that it should be possible to compress in compute, but I don't know if there's a gotcha with how compression works that would prevent this from functioning properly. If the hardware assumes the starting address of a block based on state rather than being explicitly told it wouldn't know where each block starts.

It's an interesting idea though and I'm sure developers will come up with tricks like these as this generation progresses.

Regarding the discussion about deferred rendering... Deferred rendering was a surprise during the Xbox 360 generation, but Microsoft knew about it when designing X1. They wouldn't have settled on ESRAM if they didn't think it would work well with deferred rendering.

 

[iroboto]

Regarding the discussion about deferred rendering... Deferred rendering was a surprise during the Xbox 360 generation, but Microsoft knew about it when designing X1. They wouldn't have settled on ESRAM if they didn't think it would work well with deferred rendering.

this is an obvious point I didn't consider when I wrote that. I was too caught up in this slide from AMD. Reason being I just see it as the 'target' specs that all games are likely aiming for for this generation.
edit: need to amend this as it's not telling the whole picture. If MSAA isn't required Deferred Tiled/Deferred operates faster in some scenarios, and in others it's about the same in rendering speed. I've added more pictures to provide a more holistic view.

 

[Billy Idol]

That's a silly response unbefitting of the Tech forum. If one considers the limitations of XB1 to be due to ESRAM, one can consider that a larger amount would have been better (although it'd need to be eDRAM) and solve those issues. Certainly to take XB1 as is and remove the ESRAM, you'd end up with a vastly inferior machine that knocks your point completely on its head.

If 0 is not allowed as an answer, then the question of ideal esram size seems to be ill-posed.

Of course, the choice 0 implies further changes, not only substract the esram. But so does every answer with >32MB (e.g. cost), as the actual size is 32 fitting exactly MS plan and bill. E.g. if you up esram, you up the costs...maybe these additional cost would open up an alternative solution...

But I understand what this thread is all about and hence apologize and turn to other discussions.

 

[Shifty Geezer]

If 0 is not allowed as an answer, then the question of ideal esram size seems to be ill-posed.

The question didn't really invite a clear answer because there are no standard requirements for renderers such that a specific amount of RAM is ideal. However, the question was trying to ascertain the sorts of memory requirements of renderers such that buffers could sit in local store without needing memory juggling. The answer, of course, as mentioned by other above, is 'it depends'.

 

[Billy Idol]

The question didn't really invite a clear answer because there are no standard requirements for renderers such that a specific amount of RAM is ideal. However, the question was trying to ascertain the sorts of memory requirements of renderers such that buffers could sit in local store without needing memory juggling. The answer, of course, as mentioned by other above, is 'it depends'.

Agreed

 

[zed]

What games are having 4096 lights onscreen, hell what games have 256 lights onscreen?

 

[iroboto]

Lol dunno. Sebbbi and MJP can probably comment on where the typical spot tends to be for AAA titles.

With the graph being normalized I'm not sure how much GPU time would be required to render 4096 lights either. Could be a long time lol

 

[taisui]

The slides are for forward+ rendering versus just tiled deferred, though. Tiled deferred typically has better performance than non-tiled but it's not always true, since they have different performance pattern they are not exactly interchangeable in drawing conclusions on Foward+ vs "deferred."

Ryse utilizes tiled deferred rendering as well.

 

[Strange]

Ideal is 8 Gigs of eSRAM

How large would the die be though lol

 

[iroboto]

The slides are for forward+ rendering versus just tiled deferred, though. Tiled deferred typically has better performance than non-tiled but it's not always true, since they have different performance pattern they are not exactly interchangeable in drawing conclusions on Foward+ vs "deferred."

Ryse utilizes tiled deferred rendering as well.

True; I should note that. There is a slide deck on ryse indicating that they almost went forward+ but had some problems in practice. They may revisit it; if they get through their problems.

I don't know if forward+ will come to widespread use, I believe only Dirt 3 is the only game leveraging it. Such a low adoption rate indirectly speaks for itself.

The only reason I brought it up was for the performance comparison between the two engines with emphasis that one is more ALU heavy while the other is footprint heavy. Perhaps the trade-off isn't worth it for x1 and the spill over to ddr3 is still a better solution than to eat the cost of calculating the depth buffer.

 

[Rangers]

Regarding the discussion about deferred rendering... Deferred rendering was a surprise during the Xbox 360 generation, but Microsoft knew about it when designing X1. They wouldn't have settled on ESRAM if they didn't think it would work well with deferred rendering.

I dont know, MS seems blatantly hung up on ESRAM/EDRAM (I can gather that from their touting of it last gen where I always found it arguable, to bkilian informing us that a ESRAM was decided as a pillar of X1 before 8GB RAM or much of anything else was). I can envisions some discussion like this "but ESRAM doesn't work great for todays techniques" "I dont care, put the ESRAM in!!!" "but it doesn't make any sense boss!" " I dont care, just do it!"

 

[3dilettante]

That hypothetical discussion, as written, is in the wrong tense. Any such dispute would have happened over three years ago, such is the nature of the process.

If we are to give a three year window for that decision to be proven decisively wrong, we should probably require that the armchair architects on the web wait three years to make sure they are right.

What the ESRAM attempts to compensate for is one of the fundamental problems facing all of modern computation. Whether it was hampered by one of the other massive problems facing VLSI, and whether it is the absolute right call is something I believe we should wait to determine. Even then, I doubt the answer will be as simple as the formulation put forward by most posters.

 

[Scott_Arm]

That hypothetical discussion, as written, is in the wrong tense. Any such dispute would have happened over three years ago, such is the nature of the process.

If we are to give a three year window for that decision to be proven decisively wrong, we should probably require that the armchair architects on the web wait three years to make sure they are right.

What the ESRAM attempts to compensate for is one of the fundamental problems facing all of modern computation. Whether it was hampered by one of the other massive problems facing VLSI, and whether it is the absolute right call is something I believe we should wait to determine. Even then, I doubt the answer will be as simple as the formulation put forward by most posters.

You're not towing the generally accepted narrative

 

[SlimJim]

What I still don't understand is that if even armchair architects see the major faults/cons in going with ESRAM, then how could MS have proceeded with it?

To me the only logical explanation is that they needed the TV stuff, requiring 8GB so badly, that they were willing to sacrifice:
yields, ease of programmability, graphical power.

I know that it would have been a much better choice to go with a separate ARM SOC to handle ALL of the TV stuff, including having it's own RAM. HDMI passthrough mode with the "xbox turned off" would cost 5-10 watts at the most, instead of 70+ watts. For Kinect stuff the system could be kicked out of standby, handling the voice requests.

Anyway, this way Xbox could have launched with 4-6GB of GDDR5 main ram, and the (in that case) useless ESRAM transistors could be left out; allowing for a GPU competitive with PS4.

That way you have a much more faster system, that is more energy efficient, and needs less system resources to drive the TV stuff as well. Even better, the SOC could be removed from the design the moment MS realised that nobody wants te TV stuff. Which should have been in the main planning stages! But anyway, I just made a much more flexible, as well as more powerful, Xbox One design. And the most beautiful thing is: I don't even work for MS.

There are some synthetic, hypothetical situations in which ESRAM could prove useful, but they are far outweighed, and outnumbered by all the associated cons. That's my conclusion at least.

 

[iroboto]

At this point in time, without official word from the few people that _signed off_ the call to finalize the silicon for whatever reasons, no amount of arm-chairing will ever really determine why they came to the conclusion that they did. We have at best some guesses just based upon other decisions, but that's about it. It is what it is.

I am confused as to why many believe that Kinect and TV forced them to go ESRAM. I don't see any technial benefit for TV + Kinect to be a better setup with ESRAM, than it would vs an alternative setup.

IMO This topic is now better served as a 'how to engineer with/how to architect with' ESRAM, vs what is it capable of compared to 'what ifs/the competition' as frankly the setup will never change for the lifetime of this console. It is certainly more interesting as an educational/hobbyist thread on how developers will eventually reach certain design decisions on tackling/maneuvering with this particular architecture.

 

[3dilettante]

What I still don't understand is that if even armchair architects see the major faults/cons in going with ESRAM, then how could MS have proceeded with it?

There are tradeoffs and complex design decisions that must be made years before it would be known what the reality will be.
A lot of armchair architects think Microsoft should have used super-secret die stacking so that there would be five GPUs buried under the main SOC, so why didn't Microsoft do that too?

To me the only logical explanation is that they needed the TV stuff, requiring 8GB so badly, that they were willing to sacrifice:
yields, ease of programmability, graphical power.

It's been claimed on this forum that 8 GB was not the target when ESRAM was set as a design feature.

 

[AlNom]

A lot of armchair architects think Microsoft should have used super-secret die stacking so that there would be five GPUs buried under the main SOC, so why didn't Microsoft do that too?

You're not thinking 4th dimensionally!

 

[Laa-Yosh]

I think TV and Kinect are blamed more about their overall effect on the bill of materials; if MS engineers had a larger budget, they might have decided to go with a faster unified memory instead.

Although if it wasn't for the TV stuff, the X1 may only have used 4GB... but then it would've been as easy to upgrade to 8GB as it was with the PS4.

Look on the bright side though - the different architectures mean there's still something to discuss, and maybe the limitations on the X1 will also result in some new, forward-thinking ideas...