Seems like you are having a tough time understanding what an API is.
Consoles (both the 360 and ps3) are not locked to DX9 effects even though they have DX9 level hardware.
And again, what does this have to do with deferred rendering on the 360?
*spin-off* Deferred Rendering & 360
- Thread starter Ruskie
- Start date
Seems like you are having a tough time understanding what an API is.
Consoles (both the 360 and ps3) are not locked to DX9 effects even though they have DX9 level hardware.
And again, what does this have to do with deferred rendering on the 360?
It isn't so much meaningless, as that DX11 finally allows PCs to do stuff that has been possible on consoles since 2004, not the other way around. The DX9 rendering pipeline is fairly fixed, in that various points in the pipeline are so-called 'points of no return' in terms of information/memory access. The PS3 but to some extent the 360 as well don't have this limitation per se - those just have various bottleneck limitations.
The advantage of DirectX 11 is that development studios that are primarily PC oriented or primarily multi-platform oriented can now start exploring pipelines that go beyond the traditional DirectX9 setup, on more than one platform, or more than just a small subset of PC hardware.
Didn't know Metro was fully deferred, game looked great IMO.
I also remember reading about Crackdown using deferred rendering, though I'm not sure if that game is fully deferred.
Prophecy2k
Veteran
What are the drawbacks of having to tile with a deferred renderer on 360?
Judging from the examples already quoted above of games that chose to reduce the res rather than having to tile, is that an indication that tiling is generally not the best option? And if so why is that?
Is it simply a perfomance issue in having to render polygons multiple times where they cross tiles? Is there not a way to choose tiles more carefully so as to minimise this?
They did the first pass with depth & normals, then some sort of glow card accumulation for the city lights. I'd have to refer back to ShaderX7 to get the details. Might want to check out DF's interview on Crackdown 2. I believe it was discussed briefly.
Aside from having to re-process the geometry that crosses between the tiles, there can be shaders/post-fx that cover a group of pixels between tiles. For example, Crackdown had to do a little extra pixel-rendering work so that the toon drawing didn't screw up at the tile boundaries.
There are ways to configure the tiles, but it really depends on the game whether there's a performance win or not. If you take a city-game like Crackdown it almost didn't matter which way the tiles were oriented because they were dealing with big buildings - slice the screen vertically or horizontally... you'd still get crossing-over.
You can still do hacks for DX9 API. Crysis 2 is proof of concept and previous Crysis games which relied on several hacks to workaround DX9 API limitations. Though that said perfomance gains are much better in DX10 or better.
Dont know if for 360 and/or PS3 but CE3 supports tiled deffered shading. It certainly isn't used for PC.
You can't really compare the current console GPUs directly to DirectX feature sets. Most old DX9 PC GPUs were able to render to vertex buffers for example (though a API hack) and supported various depth buffer read formats (though various API hacks) that were not officially supported.
With console hardware you can directly read MSAA subsamples, since you know exactly the memory layout the hardware outputs to, and have access to that memory. And the Xbox memexport functionality offers full programmable output (scatter) to any address. PC hardware needs DX11 compute shaders for that (DX10 stream out is more limited). And there are many other features that lower level hardware access allows.
Black Rock's engine (Blur) is also using a deferred renderer, and exactly the same resolution as Trials HD on Xbox 360. They use 4x4 microtiles in their renderer. In their papers they said that the PS3 version performance was increased drastically by the tiled system (almost doubled). The Xbox 360 version received a smaller boost.
With console hardware you can directly read MSAA subsamples, since you know exactly the memory layout the hardware outputs to, and have access to that memory. And the Xbox memexport functionality offers full programmable output (scatter) to any address. PC hardware needs DX11 compute shaders for that (DX10 stream out is more limited). And there are many other features that lower level hardware access allows.
Trials HD is using a tiled deferred shader on Xbox 360. We bin all lights to 64x48 pixel screen space tiles. All block lights are rendered in a single pass. This allows us to read the g-buffers just once for the whole lighting pass (traditional deferred needs one read per overlapping light). Tiled deferred also saves some ALU (math), as we do not need to uncompress the packed pixel normal and calculate the pixel 3d position from the z-buffer for each light. It's a good method, and is used on many AAA PS3 games. I don't know if many Xbox 360 games use it, but for us it has been really good since it was one of the reasons that allowed us to reach solid 60 fps (while still having dozens of dynamic shadow casting lights on screen at once).
Black Rock's engine (Blur) is also using a deferred renderer, and exactly the same resolution as Trials HD on Xbox 360. They use 4x4 microtiles in their renderer. In their papers they said that the PS3 version performance was increased drastically by the tiled system (almost doubled). The Xbox 360 version received a smaller boost.
Cool! So are you binning on the CPU or GPU? If the former, do you read back the depth buffer first to tighten the tile depth ranges (or are you using your conservative/speculative depth buffer that you mentioned in the SDSM thread)?
For shading then I assume you just launch a full screen quad and read the light lists for the given tile out of global memory? Or do you batch up different tiles separately to run different shaders (like the "screen-space classification" stuff from SIGGRAPH)?
I'm also assuming you refine the light lists inside a tile a bit more than 64x48, or perhaps you're just using fairly large lights so it's not a big issue?
(((interference)))
Veteran
Well it seems that Dead Space only uses light pre pass after all (see B3D interview) and Metro 2033 does the same (except with deferred reflections?)
http://www.eurogamer.net/articles/digitalfoundry-tech-interview-metro-2033?page=2
So basically BF3 will be the first boxed title to use fully deferred shading on 360. Will that be a problem for the 360 version - seeing as no other titles have gone down that route?
http://www.eurogamer.net/articles/digitalfoundry-tech-interview-metro-2033?page=2
So basically BF3 will be the first boxed title to use fully deferred shading on 360. Will that be a problem for the 360 version - seeing as no other titles have gone down that route?
Trials HD still uses fully deferred shading as far as I know.
Edit: sebbbi's post is like nearly above yours, is it that hard to notice?
Indeed. And he also mentioned Black Rock's game. Though that would be Split Second unless he means Bizarre's Blur.
Either way that game also uses deffered rendering.
Last edited by a moderator:
Or there might be another one coming out sooner ;-)
(((interference)))
Veteran
Trials HD still uses fully deferred shading as far as I know.
Edit: sebbbi's post is like nearly above yours, is it that hard to notice?
Yea, it was late I didn't read the rest of the thread (I just saw that Dead Space wasn't fully deferred and wanted to post that, since I was told otherwise before).
I have never played Trials, so I don't know how relevant it is to a AAA shooter, it's a 2.5d bike stunt game so that probably lets them get away with things that you can't do in a shooter where you have full camera control etc. similar to how LBP has all the bells and whistles you don't see in other PS3 exclusives.
I thought Blur also used light pre pass, not sure about Split Second?
Heh, I always confuse those two
In Trials HD we bin the lights to screen space tiles using CPU. The binning takes only around 1ms of a single thread (Xbox CPU has 6 HW threads). The CPU binning is done in 2d screen space only (light depth bounds are not checked using depth min/max buffer). The lighting shader first reads the z-buffer, normal buffer etc, and unpacks them (calculates with space position and 3 channel normal). For each light, we first check if the the view space position z lies inside the light area, and skip it otherwise (dynamic branching).
We have precompiled a shader for each spot/point light count combination (a bit like in the SIGGRAPH article you mention). CPU selects the shader for each tile based on the light counts. The lighting shader gets the properties of each light as static constants (GPU constant buffer). This way we do not require any dynamic looping the pixel shader (console GPUs prefer static unrolled loops). All shadow maps (ESM maps with extra alpha shadow channel) are stored in a single texture atlas, so we can read any amount of shadow maps by using a single sampler.
That's our new tech I have been doing for the last 1.5 years... I'll describe it better when it's finalized and I am also able to show some screenshots of our next game.
It's true that limited visibility range (40 meters in Trials HD) or static 2d style camera (Little Big Planet) cuts down the visible object count (and draw call count) nicely. It surely helps with performance (when rendering the objects to g-buffers). However the lighting itself is calculated the same way no matter what kind of camera the game has. Deferred shading cost doesn't scale on object count (it scales on screen resolution and light overlap in 2d screen space). So for pure lighting performance pretty much irrelevant how much objects there are in the scene... unless you are rendering a lot of dynamic shadow maps
It's actually pretty hard technically to implement a game with robust user created content support (like LBP or Trials HD), because the developers cannot precalculate or bake anything offline. Most AAA shooters still use precalculated light maps for all environment lighting, and that saves huge chunk of performance. I have high respect for the Little Big Planet team. They have made many nice technological innovations. Crytek's real time global illumination system is also really nice for future games that have high dependency on user created content (and cannot use prebaked GI lightmaps).
Neat, thanks for the explanation! Looking forward to hearing about your new tech as well when it is finalized
(((interference)))
Veteran
It's true that limited visibility range (40 meters in Trials HD) or static 2d style camera (Little Big Planet) cuts down the visible object count (and draw call count) nicely. It surely helps with performance (when rendering the objects to g-buffers). However the lighting itself is calculated the same way no matter what kind of camera the game has. Deferred shading cost doesn't scale on object count (it scales on screen resolution and light overlap in 2d screen space). So for pure lighting performance pretty much irrelevant how much objects there are in the scene... unless you are rendering a lot of dynamic shadow maps
It's actually pretty hard technically to implement a game with robust user created content support (like LBP or Trials HD), because the developers cannot precalculate or bake anything offline. Most AAA shooters still use precalculated light maps for all environment lighting, and that saves huge chunk of performance. I have high respect for the Little Big Planet team. They have made many nice technological innovations. Crytek's real time global illumination system is also really nice for future games that have high dependency on user created content (and cannot use prebaked GI lightmaps).
Oh of course, yes I forgot about that (it is the primary advantage of deferred shading after all!)
So why do you think no other developers have gone with fully deferred shading on 360? Do the disadvantages outweigh the benefits for most titles with a fully player controllable camera? Or are developers simply not interested in tackling the challenge of building a fully deferred renderer on 360? Do you think developers like DICE who are going down this route this will find maintaining parity with the PS3 difficult?
You can always choose deferred light pre-pass rendering as an alternative which would also allow for more material variety. Can anyone point out the pro/con features of going fully deferred vs. light pre-pass?). I personally get the impression that light pre-pass is easier to implement across multiple platforms (GTA4/RDR, Dead Space 2, Crysis 2) or even on the 360 (Halo Reach) - but there must be some disadvantages too.
The only two fully deferred engines running AA games in this generation seem to be Killzone2/3 and BF3, and to get it working on PS3 with HDR, Dice had to move shading to the SPUs and optimize the hell out of it. This gives me the impression that this is not an easy task.
Also, in the long term it might not be a viable solution. I'm not sure which was the first, but offline CG has been relying on post processing lighting in compositing for some of the shots for many many years by now. It also involves diffuse/normal/depth/spec channels and lighting in 2D, but the precision and quality have always lagged behind traditional rendering, so it's reserved for specific stuff like tweaking the last 5% of lighting or adding sudden flashes and so on.
Still, BF3 looks damn good so the trouble in the past might had to do more with improper gamma and nonlinear lighting. Maybe deferred rendering is the future for all realtime engines.
The only two fully deferred engines running AA games in this generation seem to be Killzone2/3 and BF3, and to get it working on PS3 with HDR, Dice had to move shading to the SPUs and optimize the hell out of it. This gives me the impression that this is not an easy task.
Also, in the long term it might not be a viable solution. I'm not sure which was the first, but offline CG has been relying on post processing lighting in compositing for some of the shots for many many years by now. It also involves diffuse/normal/depth/spec channels and lighting in 2D, but the precision and quality have always lagged behind traditional rendering, so it's reserved for specific stuff like tweaking the last 5% of lighting or adding sudden flashes and so on.
Still, BF3 looks damn good so the trouble in the past might had to do more with improper gamma and nonlinear lighting. Maybe deferred rendering is the future for all realtime engines.