By using this site, you agree to our Privacy Policy and our Terms of Use. Close

Forums - Microsoft - sebbbi (Xbox One programmer) on B3D lays out effective use of ESRAM (technical)

mutantsushi on 26 February 2014

Unless MS has a secret sauce they are poisoning good PS4 programmers with, good XBone programming cannot change the significant power difference.

Good programming is perhaps more important to make decent baseline use of XBone, but the hardware has a lower ceiling than PS4.



Around the Network
JoeTheBro on 26 February 2014

I made a good thread explaining this http://gamrconnect.vgchartz.com/thread.php?id=179121&page=1#



Links

Sevengen on 26 February 2014
mutantsushi said:
What those devs prompted me to think was: there will be rather different optimization paths for x-platform vs. native PS4 games.
The former will not really play to PS4's strengths as much, which is stuff that XBone simply cannot attempt,
but PS4's compute unit and GPGPU thread advantage (ROP to some extent, although with the 64bit GCN as mentioned, that may not be as hard a limit as previously thought)
all will be able to gain some advantage over XBone, including framerate but potentially other aspects of rendering.
You can see in their convesation the XBone dev is talking about reducing the quality of certain things, or relying on main memory to keep up, and flat out ignoring some lighting techniques...
The fact that the XBone dev talks about using GPGPU compute to enable parity, while XBone's GPU is both gimped in compute units and GPGPU threads seems like that is pushing hard against their limit,
the PS4 doesn't need GPGPU for that, but has plenty of it on call for whatever they want to use it for (including efficiencies mentioned by the XBone dev, which just allow the PS4 even more bandwidth for other things).
It's sad that people who can't remotely follow this stuff get distracted by things like 1080p or even frame rate and treat them as fixed points of comparisons,
they are merely one side effect of GPU power, while things like shadows, lighting, tesselation and AA are other usages.
It's hardly that it is IMPOSSIBLE for XBone to EVER have 1080p games, it is just that PS4 has more power to deliver richer experiences by whatever metric.

so by that logic, the original Xbox delivered richer experiences.. by whatever metric.. than the PS2. Right?
oh yeah, almost forgot.. and the Gamecube, that also delivered richer experiences.. by whatever metric (lol).. than the PS2. Right?
Hmm. How about the Dreamcast, that obviously delivered richer experiences.. by whatever metric.. than say the N64.
See.. I get where you're going.
You're saying that the 'more' powerful consoles have always delivered richer experiences.. by whatever metric.. than the lesser powered consoles.
Yeah.
You couldn't be more right.



mutantsushi on 26 February 2014

If you're talking about hardware, sure.
If you're talking about hardware, you're talking about what is independent of the game developer.
If you're not talking about hardware, then you don't belong in a hardware discussion thread.

If you don't understand that, I assume you are very angry for Sony overcharging for 1/3 of a GPU that does nothing useful,

and for every PC GPU OEM overcharging for everything beyond their low-mid-end GPUs. 

Or else GPUs actually matter in terms of what the hardware can contribute to a game experience.



WagnerPaiva on 26 February 2014
Goatseye said:
WagnerPaiva said:
 


More popular than PES, that is for sure, and I am sick of those as well. Gimme Star Ocean, Silent Hill, Valkyria Chonicles, Metal Gear...

I thought Brazilians were born with a soccer ball. You must be a rebel...

I would say, 20% of the population hate soccer, 30% enjoys it, 50% love it.

I don´t like it. Not one bit.



My grammar errors are justified by the fact that I am a brazilian living in Brazil. I am also very stupid.

Around the Network
hieuth09 on 26 February 2014
NobleTeam360 said:
*Reads article not understanding anything they said*


Same feelings, just want the products so far ... just enter this thread to read comments :v



Sevengen on 26 February 2014
mutantsushi said:

If you're talking about hardware, sure.
If you're talking about hardware, you're talking about what is independent of the game developer.
If you're not talking about hardware, then you don't belong in a hardware discussion thread.

If you don't understand that, I assume you are very angry for Sony overcharging for 1/3 of a GPU that does nothing useful,

and for every PC GPU OEM overcharging for everything beyond their low-mid-end GPUs. 

Or else GPUs actually matter in terms of what the hardware can contribute to a game experience.

If you're talking about hardware, you're talking about what is independent of the game developer.
   
when you said 'richer experience' were you talking about sitting on the couch and staring lovingly at your console? Probably not. So.. you must have been referring to the software. Yes?.. Of course you were.

If you're not talking about hardware, then you don't belong in a hardware discussion thread.

These are gaming forums and they're all interrelated, so if I want to make comments about gaming and related subjects.. I belong in any thread I choose to open, read, and feel compelled enough to reply in. And once again, using your own logic against you.. if this were strictly a hardware discussion, you wouldn't have made reference to the software experience. Right?
But you did, and I called you on it.

Now, if you'll excuse me, I'm going to go play my Xbox because (of it's sheer power) I'm still enjoying the richerer experiences I had with it over the PS2. lol.



DJEVOLVE on 27 February 2014
JoeTheBro said:
I made a good thread explaining this http://gamrconnect.vgchartz.com/thread.php?id=179121&page=1#


Yes your vgchartz 100th expert. Where do you work and what games have you made?



JoeTheBro on 27 February 2014
DJEVOLVE said:
JoeTheBro said:
I made a good thread explaining this http://gamrconnect.vgchartz.com/thread.php?id=179121&page=1#


Yes your vgchartz 100th expert. Where do you work and what games have you made?

I'm one of the few devs on this site, sure, but that doesn't really matter here.

I'm not using an "I'm right you're wrong attitude," but rather just explaining the situation. The explanation in that thread isn't even that technical. I purposely kept it simple so that almost any gamer could follow along. Do you disagree with anything I said in that thread?



Links

ICStats on 27 February 2014
fallen said:

Thought this was fun though technical. Seems proof Xone can be a beast.

 

First MJP, who works at Ready at Dawn (The Order 1886 guys) had this to say, seemingly painting a difficult picture of working with the ESRAM, specifically fitting everything in 32 megabytes(Though he admits he has never worked with Xbox One, only PS4)

 

Deferred renderers are *very* common for next-gen titles, especially those in development. With the major middleware providers all using deferred rendering, games using forward rendering are very likely to be the minority from this point on (even considering games using Forward+/Tiled Forward/whatever you want to call it).

Back when we were in the prototype stage we were using a deferred renderer, with a tiled compute-based approach similar to what Frostbite uses. At the time we had a G-Buffer setup like this:

Lighting target: RGBA16f
Normals: RG16
Diffuse albedo + BRDF ID: RGBA8
Specular albedo + roughness: RGBA8
Tangents: RG16
Depth: D32

So if you're looking to target 1920x1080 with that setup, then you're talking about (8 + 4 + 4 + 4 + 4 + 4) * 1920 * 1080 = 55.3MB. On top of that we supported 16 shadow-casting lights which required 16 1024x1024 shadow maps in an array, plus 4 2048x2048 cascades for a directional light. That gives you 64MB of shadow maps + another 64MB of cascade maps, which you'll want to be reading from at the same time you're reading from your G-Buffers. Obviously some of these numbers are pretty extreme (we were still prototyping) and you could certainly reduce that a lot, but I wanted to give an idea of the upper bound on what an engine might want to be putting in ESRAM for their main render pass. However even without the shadows it doesn't really bode well for fitting all of your G-Buffers in 32MB at 1080p. Which means either decreasing resolution, or making some tough choices about which render targets (or which portions of render targets, if using tiled rendering) should live in ESRAM. Any kind of MSAA at 1080p also seems like a no-go for fitting in ESRAM, even for forward rendering. Just having a RGBA16f target + D32 depth buffer at 2xMSAA requires around 47.5MB at 1920x1080.

 

Then Sebbbi, who works on the Trials HD series, responds

MJPs g-buffer layout is actually only two RTs in the g-buffer rendering stage and one RT in the lighting stage. And a depth buffer of course. Quite normal stuff.

On GCN you want to pack your data to 64 bpp (4 x 16 bit integer) render targets because that doubles your fill rate compared to using more traditional 32 bpp RTs (GCN can do 64 bit filling at same ROP rate as 32 bit filling).
I assume that the packing is like this:
Gbuffer1 = normals + tangents (64 bit)
Gbuffer2 = diffuse + brdf + specular + roughness (64 bits)
Depth buffer (32 bits)
Without any modifications this takes 40 megabytes of memory (1080p).

The lighting step doesn't need extra 8 MB for the 4x16f RT, because compute shader can simultaneously read and write to the same resource, allowing you to to lighting "in-place", writing the output over the existing g-buffer. This is also very cache friendly since the read pulls the cache lines to L1 and the write thus never misses L1 (GCN has fully featured read & write caches).

It's also trivial to get this layout down to 32 MB from the 40 MB. Replace gbuffer1 with a 32 bit RT (32 MB target reached at 1080p). Store normal as 11+11 bit using lambert azimuth equal area projection. You can't see any quality difference. 5+5 bits for tangents is enough (4 bits for exponent = mip level + 1 bit mantissa). 11+11+5+5=32. Also if you only use the tangents for shadow mapping / other planar projections, you don't need them at all, since you can analytically calculate the derivatives from the stored normal vector.
This layout is highly efficient for both g-buffer rendering and lighting. And of course also for post processing since all your heavy data fits in the fast memory. Shadow maps obviously need to be sampled from main memory during the lighting, but this is actually a great idea since the lighting pass woudn't otherwise use any main memory BW at all (it would be completely unused = wasted).

A good exchange and an indication to me that the ESRAM can do nice things if worked with. It seems like MJP thought there would be memory issues with 32MB ESRAM at 1080P, but Sebbbi shows with clever optimzation it all MJP's example can be nicely packed in 32 MB's.

These notes are correct for squeezing in the G-buffers @ 1080p into 32MB of RAM, but the following points from MJP still stand:

  • The point about MSAA.  If no MSAA takes 32MB then 2xMSAA or 4xMSAA would take 64MB and 128MB respectively.
  • The point about using up to 128MB of shadow maps at the same time.
Also I'll add a couple of points:
  • Rendered buffers like the resolved color buffer and shadow maps will need to be shipped from ESRAM to main RAM at some point.  This will obviously take some time and bandwidth of it's own.
  • Sebbi says GCN can do 64bit RTs just as fast as 32bit RTs.  I wonder if that's true for XB1, since it has slightly different GCN than PS4.
  • The ESRAM only addresses the bandwidth gap.  What about the compute units gap?
Anyway I could be wrong, but MS "1080p SDK" could be just something like ESRAM extension if they didn't already have that.  This is where you use page mapping to essentially extend the ESRAM above 32MB with normal RAM.
So let's say you have 40MB of buffers, you put them in 32MB ESRAM with an 8MB RAM extension.  Anything that draws to the 8MB RAM is going to be slow, but 80% of the time you access the fast ESRAM, and overall it's convenient for developers.



My 8th gen collection