Andrew, isn't your comparison different? Forward+ uses light tiles to avoid having to write a G-Buffer.
The "tiled deferred" implementation in that demo should be similar to mine and that's what I was comparing. As I noted, I imagine the disparity comes from just massive ALU saturation when you set it to 1024 lights in MJP's demo. With 128 lights the results are more similar to mine.
Indeed I don't implement the "forward+" (personally I'd still call this closer to deferred than pure forward, but that's just me
), but I wasn't looking at those numbers.
Judging from your slides, the MSAA perf hit with deferred - even with your fancy edge detection and pixel repacking - is greater than what you see with most forward rendered games. I'm also sure that the render time should be significantly faster without having to write/read a G-buffer. As nice as that perf boost would be, the biggest strength of Forward+ is probably shader variety.
So called "shader variety" is a totally red herring. Deferred can run arbitrary shaders just as efficiently as forward (sometimes more-so due to 2x2 quad scheduling from the rasterizer). Try it
And sure you avoid reading/writing the G-buffer (once), but you re-render/transform/tessellate/skin all your geometry. So it's app and scene dependent which is faster of course.
Also, despite forward rendering MSAA being inefficient on small interior triangle edges, it is a form of selective supersampling that can be very important for specular surfaces, so you'd have to identify those areas in the deferred to make it truly apples to apples.
It doesn't make a difference in practice unless you're rendering your entire mesh with that high density and even then, it's a bad way of doing it. In fact in case where it was visible it would produce objectionable problems that would reveal the mesh tessellation, so I'm not sure this should ever be considered desirable.
I'd give that one to deferred again, because you can selectively super-sample wherever you like, not just at triangle edges. I refuse to be shackled by the rasterizer in terms of shader execution and evaluation
Anyways I should write a big blog post about this at some point, the main point being "these are all variants of similar ideas - test them all and use the best. It's just normal code optimization." The only reason people seem to think these are fundamentally different things is because of the semi-bizarre way that you write code in the graphics pipeline. In fact I would wager that's pretty much the entire reason for people tending to have a bias against deferred from a conceptual point of view... but try to separate out thinking of how one might write the code from how it gets executed. It doesn't end up being as different as one might think, and long term the ease of writing code is irrelevant. Frankly any decent engine should be able to generate the shaders to swap between forward and deferred with the click of a button.
The only really important point is doing culling with knowledge of the depth buffer and semi-hierarchically. In fact, all of these GPU tiling variants are doing light culling *really inefficiently* (tons of redundant computation) due to the GPU programming model, so I'm more interested in seeing that addressed than more variants of how to launch the shading work. At the moment the CPU can cull the light lists significantly faster than the GPU (!), and yet it's still a win over conventional methods which really demonstrates how bad those methods were
That's not to say it isn't good to test and document all this stuff, but there's really nothing interesting to talk about from a research point of view IMHO. All of the tiled variants can produce identical results with similar levels of efficiency. It's literally just constant factors we're playing with here and they vary per application.
