Jump to content

  • Log In with Google      Sign In   
  • Create Account

Post processing pipeline - pass count makes sense?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 N.I.B.   Members   -  Reputation: 1195

Like
1Likes
Like

Posted 24 October 2013 - 03:24 AM

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.

 



Sponsor:

#2 Juliean   GDNet+   -  Reputation: 2721

Like
1Likes
Like

Posted 24 October 2013 - 04:58 AM

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;
}

Edited by Juliean, 24 October 2013 - 04:58 AM.


#3 InvalidPointer   Members   -  Reputation: 1443

Like
1Likes
Like

Posted 24 October 2013 - 08:16 AM

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.

 

- No reason you can't use the bloom texture as input for average luminance. Sample the lowest MIP level, do a luminance calculation on that. It doesn't work out to the same thing mathematically, but you're generally not after that; the core 'darken the scene if it's really bright, lighten if the reverse' will still behave as normal.

 

- Merging passes generally requires extra work on your part. You can merge depth of field and motion blur calculations somewhat by using a skewed disk sampling pattern as demonstrated by LittleBigPlanet and (I think) Crysis 2. Tonemapping can trivially be slapped on the end of the pass immediately preceding it, as can film grain.


clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

#4 N.I.B.   Members   -  Reputation: 1195

Like
1Likes
Like

Posted 25 October 2013 - 02:25 AM

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.


Edited by satanir, 25 October 2013 - 02:32 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS