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. 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. |
LINK please.