Hi,

I just finished implementating a post-processing pipeline in my renderer. Its initial performance is better than I expected, but I still need to optimize it a bit.

One of the things that worries me is the number of passes (by pass I mean single full-screen-quad draw call, so single gaussian blur has 2 passes - BlurU and BlurV). This is how the pipeline looks:

- Screen Space Subsurface Scattering - 6 passes(3 gaussian blurs). I use stencil and depth test to avoid unnecessary pixel blurs.

- Bloom - 7 passes(1 bright pass filter, 3 gaussian blurs).

- HDR Tone Mapping - 2 passes - create luminance texture, generatemips for average, than tone map. I read MJP's post about using CS instead of generateMips, it's on my todo list.

- DOF - 3 passes (generate CoC map, 1 gaussian blur).

- Film Grain - 1 pass. This is the easiest one to remove, which I tried, but perfroance stayed the same.

So my starting point is 19 passes, most of them blurs so heavy on the TXS. I've tried removing some, but it affects the visual quality. What I'm trying to do is improving performance while preserving the visual quality, and if possible, preserve the pipeline flexibility.

I have some ideas, mainly:

- Use CS for better sampling efficiency.

- Widen the blur kernels while reducing the number of blurs. This will reduce the total amount of TXS ops, but will probably reduce the visual quality.

- Merge passes. Not sure how that will work.

Any advice will be appreciated.

You could reduce some of the passes used for blurring by using a different kind of blur, that does vertical and horizontal blurring in one pass. Don't know its exact name anymore, and don't know how it would affect visual quality, but here it is:

cbuffer stage : register(b2)
{
	float2 cTextureSize;
}

sampler InputSampler : register(s0);
Texture2D Input  : register(t0);

float4 mainPS(VS_OUTPUT inp) : SV_TARGET0
{
	float2 uTexelSize = 1.0 / cTextureSize;
	float result = 0.0;
	for (int i = 0; i < 4; ++i) {
		for (int j = 0; j < 4; ++j) {
			float2 offset = float2(uTexelSize.x * float(j), uTexelSize.y * float(i));
			result += Input.Sample(InputSampler, inp.vTex0 + offset).r;
		}
	}
	
	return result / 16.0;
}

Reading my initial post, the problem statement is not accurate.

My problem is actually the insane amount of texutre-sampling ops I'm doing, which is implied from the number of render-passes I have.

The obvious solution is to reduce the size of the kernels, which I tried, but in some cases it creats noticable visual artifacts. Another solution would be to use less TXS-heavy techniques - I've tried a couple of different techniques, I'm pretty happy with I do right now.

That leaves render-pass reduction/merging.

No reason you can't use the bloom texture as input for average luminance

Your'e talking about the bright-pass texture, correct? It contains a lot of blacks, so can't use it as-is for luminance. I do like the general idea, though. I currently don't use the alpha channel of the bright-pass map, can store the luminance value there.

Tonemapping can trivially be slapped on the end of the pass immediately preceding it, as can film grain.

Tried that, very minor performance improvment.

You can merge depth of field and motion blur calculations somewhat by using a skewed disk sampling pattern

I was thinking of doing something similar with DOF and subsurface-scattering. It does look like a lot of work (both coding and doing math). I wonder if it's worth it, performance-wise.

I've reached my performance goal (which is good), but with very little performance to spare(which is OK for now).

Still, I'm very interested to hear from others on their post-processing pipeline approach/optimizations/design.