I'd personally go for the more drastic change. There are going to be some PP effects that you're going to want to render after text/HUD/GUI/etc (I personally implement brightness/gamma using PP these days as it plays nicer with windowed modes and doesn't screw up the user's desktop post-crash) so enabling that seems a good idea.

Regarding your last question, what I've done is implement a simple "render target manager" that handles switching of render targets and storing out the current one so that it can be grabbed for input to anything that needs it. It's not as robust or elegant as I'd like, but it suffices for my own purposes.

I handle rendering and post-processing by different "scenes". In this context, a HUD is its own scene (this gives way to 3D HUDs without worrying about intersection with world objects) and the game world is its own scene.

This is not the same as grouping different meshes by different shaders, because a rendered scene output is a flat image that can get layered on top of other renders. Each scene has its own "render path" to take, allowing different processes, like forward rendering with deferred rendering. The render path also has optional PP steps.

The way it works is, first, I clear the screen. Then, for each scene, render it through its render path. Each "step" in the path is a self contained rendering class with common properties being it can take meshes, cameras or render targets as inputs. Classes may be reused for different scenes. PP steps usually only take render target inputs, and 3D rendering steps take cameras and meshes. But they all output render targets. At the last step, output the final render target, and continue with the next scene. Each render path shares a pool of render target textures.

These renders are layered back to front so I would render the HUD last, with its own rendering technique. As the layers have a transparent background, scenes with some PP effects can blend infront of others. For instance, if you wanted to make some kind of "glow" shader for the HUD with blur and light bloom, the glowing edges will be visible on top of the render of the game world.

I think it would be overkill to have many separate layers of stuff being rendered (and could hurt performance with many screen-sized quads) but I see it being useful for separating a few scenes as being considered tied to different game components, since the HUD and game world operate under different logic and input rules.

Incidentally, if I have a shader technique with more than one pass, do I always have to feed the second one with the rendered results of the first? I'd have thought the underlying libraries would know that by default and somehow do it automatically. I use 2 passes with my Gaussian blur shader, horizontal and vertical, and my application code has to feed the results of the horizontal one into the vertical one. I guess the underlying system can't always know what we're trying to achieve....

Thank you both. I really like the idea of separate renderers for each screen layer and, in fact, I was going to add 2 screen layer bits to my sorting mask but, as you've alluded to CC, I wouldn't be able to add post processing effects to each layer separately (I'm not sure I'd really need this for my game).

That's not exactly correct. You would be able to add different effects to each layer, or different combinations of effects. Each layer just will not have an effect on each others' rendering pipeline.

Take this example where [SR] is a scene renderer and each [PP] is a post-process effect. They chain together (as a list or a directed tree) to perform the steps in order and produce the final output.

layer 1

[SR1]-->[PP1]-->[PP2]--> buffer

layer 2

[SR1]-->[SR2]--> buffer

In layer 1, a scene is rendered in just one step, and two post-process effects are added to that render. In layer 2, one scene is rendered, then a second scene (or it could be the same scene using a different shader), and SR2 depends on a render target created by SR1.