....Something else that further encouraged its (deferred rendering's) adoption has been the work carried out by Sony's internal R&D team to standardize deferred rendering as something that can be used on Playstation 3.
As well as being widely distributed within Sony studios, the results of this labour have found their way into some high profile multi-format games. Collaboration with Rockstar resulted in its use in the RAGE technology that powers GTA IV, for example. Media Molecule's LittleBigPlanet and Guerilla's Killzone 2 are two Sony backed games that make the most out of the additional control and sophistication it enables in terms of game lighting.
Deferred Rendering is defined by creating a G-Buffer, isn't it? So no G-Buffer = no Deferred Rendering.
Light indexed deferred renderers do not have g-buffers. You have light index buffers instead.
We were evaluating a lot of different deferred shading (and forward shading) methods for our new Xbox 360 game, and LIDR was the best method when used in combination with stencil shadows (our older PC SM2.0/3.0 engine used stencil shadows). However LIDR is not that well suited for shadow mapped lights, and stencil shadows are no longer that attractive shadowing method (high geometry complexity and depth complexity cause huge overdraw and fill rate cost... and non-geometry occluders cannot be supported).
So in the end we were bounding back and forth between forward rendering and standard deferred shading. Our deferred renderer used KZ2/Uncharted style screen split into quads and rendering multiple lights per at once, however we added depth bounds test to the lights to speed up the performance (downscaled depth buffer storing min and max depth of the quad).
According to our testing, deferred shading seems to be the best fit for performance this generation when antialiasing is not used, and the performance advantage should increase in the future. In our testing, deferred shading had slightly better performance even when all local lights were disabled: only a single sunlight with 3 split PSSM shadow map with ESM filtering (for soft shadows) and gray scale alpha masks (for transparent occluders).
The slight deferred shading performance advantage was mainly explained by reduced shader overdraw:
1. Hi-depth culling is not pixel precise: overdraw near all depth boundaries (fences etc have 2 x overdraw, and 3 x for two fences, etc)
2. Hi-depth culling bit depth is limited: 2x overdraw on surfaces near each other (signs, posters on walls, etc)
3. Object inner overdraw: Object polygons are only presorted (tipsify) and it's not perfect on all view angles. On worst cases this can cause 2-3x overdraw on a single object.
The average pixel overdraw was around 1.4x for our average scene (we depth sorted objects by center points), and around 4x for the most pathological cases (looking a wall with a large poster though a fence). Deferred sharing guaranteed that we only process each light once per pixel. The cost of the g-buffer rendering with only one light was almost equal to the cost saved by the average 1.4x overdraw (lighting shader is very expensive compared to the shader that renders the g-buffer). And with multiple local lights deferred shader got considerably faster.
Other reasons for deferred renderer performance increases (over forward renderer) was the much reduced need for state changes and light processing during the scene rendering (this mainly reduced CPU load) and we could do more precompiled static shader versions instead of relying on static brancing on shaders (a small perf hit for the shaders). With deferred sharing the lighting and g-buffer rendering shaders can be completely separated, and this dramatically reduces the need of different shader combinations (n+m instead of n*m).
I expect many developers in the future reach similar conclusions. However deferred shading has it's weaknesses. The extra antialiasing cost is the main issue. The extra memory usage is not that big deal, and according to our testing deferred shading only consumes very little extra bandwidth (the less overdraw means less sampled shadow map pixels, etc...).
