8 replies to this topic

[lipsryme]

Let's say I have a technique that I want to implement e.g. SSAO.
This technique has to be done in 2 parts, computing the occlusion and blurring the result.

What I want to know is what would be the best way/design to approach this.
Do I have 2 seperate shader files, which means I have to have 2 seperate shader interfaces inside my application for each of the 2 parts or is it better to have a single shader that has both shader functions inside and then call these with a macro define ?

Edited by lipsryme, 01 September 2012 - 09:09 AM.

[PhillipHamlyn]

Is this the same as a multi-pass shader ? I.e. one technique with two passes; therefore one shader interface ?

[lipsryme]

Well no I'm not talking about using an effect file with technique and passes but what I'm doing is compiling the pixel and vertex shader seperately.

Edited by lipsryme, 01 September 2012 - 09:45 AM.

[CryZe]

If you're compiling them separately, there's no way to do both passes in a single shader. A shader is a program running on a Warp / Wavefront. To be able to blur the result of the SSAO, you would need to synchronize the whole pipeline accross all the different Warps / Wavefronts. The driver controlled by DirectX needs to synchronize them. That's why it's impossible. The Effect framework introduces such features in the HLSL language but actually executes them as DirectX function calls and splits the different passes and techniques into individual shaders, but hides that from the user.

Edited by CryZe, 01 September 2012 - 10:24 AM.

[lipsryme]

What I meant by that was having a single file and using #define macros to run the first function that does the computation and then a second function that does the other part. Of course rendering these two seperately. Is that not possible ?

Edited by lipsryme, 01 September 2012 - 10:36 AM.

[Jason Z]

Technically speaking, you could write a compute shader that was able to calculate the occlusion and then filter it all in one pass. It would be horribly inefficient, but it would technically be possible since you are only interested in a small neighborhood of pixels when blurring. Probably this would be something like an academic exercise, rather than what you would want in your actual game / engine.

Instead of doing that, you would be much better off separating these two passes of the algorithm. The biggest reason is that you can then use a separable filter, which is a huge win when you are using a large filter radius.

[Hodgman]

and then call these with a macro define

If you're using a #define to select the function, that means you're compiling the shader multiple times (once for each option).

Well no I'm not talking about using an effect file with technique and passes but what I'm doing is compiling the pixel and vertex shader seperately.

If you're compiling the shaders yourself, then whether you put all the code in one file (and compile 2 different shaders using different #defines or different entry points), or whether you put the code in two files, make no difference. It's just a matter of style. In the end you still end up with 2 shader binaries in either approach.

[lipsryme]

If you're compiling the shaders yourself, then whether you put all the code in one file (and compile 2 different shaders using different #defines or different entry points), or whether you put the code in two files, make no difference. It's just a matter of style. In the end you still end up with 2 shader binaries in either approach.

Well that was my question. What the design choice would be in this case...using defines makes it easier for me inside the application code, though might make the shader code less readable... I guess there's no right or wrong.

Edited by lipsryme, 01 September 2012 - 11:33 AM.

[CryZe]

using defines makes it easier for me inside the application code

Why would it make it easier from the application? You still have two shader binaries, like Hodgman said. The only thing you could do, is either writing your own library that hides "global synchronizations of the pipeline" or you use the Effect framework. A single shader can't do that.

Technically speaking, you could write a compute shader that was able to calculate the occlusion and then filter it all in one pass. It would be horribly inefficient

I think an efficient implementation might actually be faster. Simply cache the depth values and the resulting ambient occlusion values in groupshared memory. If you manage to do the necessary calculations on a single Warp, you can synchronize the threads and in that way implement the AO calculation, the horizontal blur and the vertical blur in a single shader. And since the whole process only requires one actual read and write to the VRAM, it should be way faster than a pixel shader implementation with 3 passes.