Can GSDX use multi-pass shaders ?

[KrossX]

just now it's one big shader instead the smaller ones. it still does all the passes aka that functions. you GET IT NOW ?!?

It... wouldn't be the same. >_<

The functions that use a single sample would be better off as a single shader/pass. While the ones that require multiple samples, might be more efficient as multiple passes. Like the blur example.

Thanks for responses so basically GSDX is limited to single-pass but Asmodeans shaders are complex so they have effects of multiple simpler shaders in one shader.

Exactly. He would probably welcome a better implementation for the post processing effect.

[Monochrome100]

It... wouldn't be the same. >_<

The functions that use a single sample would be better off as a single shader/pass. While the ones that require multiple samples, might be more efficient as multiple passes. Like the blur example.


Exactly. He would probably welcome a better implementation for the post processing effect.

Yes me too, would be great if PCSX2 could use multi-pass shaders like Retroarch.

[dabore]

... Like the blur example.

yo i get this. the blur is an exception. i know one would need the extra preblur. it was a bad example. but it's was just to show the functional style of the shaders. neither relevant to gsdx. who needs blur in there?

[KrossX]

How come?

I think this should be just some kind of composition (mathematics) of shader functions, or? if you now use shaders s1,s2,s3 with one effect per shader in a way that you get a Multiple shader:

Code:

output = s1(s2(s3(input)));

there is no difference to one single shader ss with multiple effects

Code:

ss(input)
{
return effect1(effect2(effect3(input)))
}
output = ss(input);

Am I missing something? The first example seems to be better encapsulated and maybe easier to configure for the enduser. But in the end they are the same.

That would be fine for things that use a single sample, like the Shadeboost shader.

Let's do the blur example again. This blur effect requires nxn samples depending on the quality of the blur you want. So a single pass blur of n = 9 requires 81 samples. Those are 81 slow sample requests on the gpu. In the cpu program it could be like:

compile_shader("blur.fx", "main").use();

The blur has a symmetry however, in which doing a horizonal blur and applying a vertial blur to it would yield the same result. But a horizonal line is 9 samples and so is the vertical one. Thus, it's only 18 samples vs 81.

compile_shader("blur_horizontal.fx", "main").use();
compile_shader("blur_vertical.fx", "main").use();
or...
compile_shader("blur.fx", "main_h").use();
compile_shader("blur.fx", "main_v").use();

Doesn't matter, what matters is that the gpu is executing two shader programs instead of one. There's a cost, but you save tons of samples. In the end you get the same effect, a blurry image of nxn quality.

-------------------------------------------------------

Another example, order dependency.

Suppose you have FXAA, and then you want to blur things up. FXAA requires a number of samples, let's say 4. And this cheap blur also requires 4 samples. In a single pass, without any attempt at optimizing anything...

if you do output = blur(fxaa()), you'll end up with an aliased image. Why? Because even though blur got a result from fxaa, it will take other 3 samples (cuz it uses 4)... from a buffer that has no fxaa applied to it.

So for the blur to be totally fxaa'ed, it would need to apply fxaa to each sample it uses. It means that the fxaa function runs for each blur sample. The blur function uses 4 samples, and each one runs fxaa and uses 4 itself so each blur uses 16 samples total.

So for each blur call, on each sample (or pixel), blur runs once, fxaa runs four times, and 16 samples are requested. Depending on the resolution, the extra work quickly adds up.

Now with two passes.....

first, ouput = fxaa(), fxaa runs once per sample and requests 4 samples.
then, output = blur(), blur runs once per sample and requests 4 samples. With blur running on the result of fxaa.

In total, for each final sample, blur runs once, fxaa runs once, and 8 total samples are requested.

------------------------------------------------------

It's the same result, but one is more optimal and easier to deal with. And no matter how many shader files you end up with, you can still use a single settings file like Asmodean currently uses.


Woah this ended up long... sorry.

[dabore]

just thought how cool it would be if the pixel shaders would run fluid over the lines and keep the registers intact per pixel. you'd need to only take one sample forward into a register that you could - given you do power of two sample counts - index adress with a modulo from an integer of the x or y coordinate. it would automaticly discard the top/left most sample. just gotta sub the discarded before and add the new pixel color to a temporal color merged register. then multiply by the inverse of the sample count and write. and jump to next pixel. that'd be a a f*cking fast line blur shader. do compute shaders do that?

[KrossX]

I have no idea of what you just said. But you might wanna check, and anyone interested in the subject, the following... blog series: A Trip Through the Graphics Pipeline.

It's a pretty good read.

[dabore]

you found herrn giessen's blog? awesome.

and i actually looked at the compute shader implementation for the line blur. the shader threading is kinda weird and i don't really get that tls concept. but it's indeed doing it with that one sample per pixel thread that is added to a line storage where the samples are taken from and per thread it shifts the sample window. it just computes the blur color all the time with the modulation of the full sample count. not what i thought. and it's really faster. that's how i looked at that.

[Monochrome100]

By the way can GSDX use geometry or tesselation shaders ?

[bigpet]

@Monochrome100 For what? I can't think of a single generally useful application to insert random geometry or tesselation shaders.

[Monochrome100]

@Monochrome100 For what? I can't think of a single generally useful application to insert random geometry or tesselation shaders.

So I understand it doesnt, they would allow for more advanced shaders.