GLSL and MRT

[tang_m]

Hi, Could it possible to use GLSL achieve MRT effect?
In HLSL,

struct PS_OUTPUT {
float4 color : COLOR0;
float4 normalZ : COLOR1;
};

PS_OUTPUT psMain( PS_INPUT i )
{
PS_OUTPUT o;
…
return 0;
}

But in GLSL, by extension “ATI_draw_buffers“ I can provide MRT, but fragment program can only write gl_FragColor. If I can compress float data, I can managed to compress position, normal information into RGBA channels. Are there correspond functions of “PK2H, PK4B, UP2H, UP4B” in GLSL?

[Corrail]

I think (hope) GLSL will support MRT with the upcomming Superbuffer extension. Till then I think you have to use ATI_draw_buffer with GL_Fragment_program...

[mrbill]

Originally posted by Corrail:
I think (hope) GLSL will support MRT with the upcomming Superbuffer extension. Till then I think you have to use ATI_draw_buffer with GL_Fragment_program...

If you remember from the original proposals,
there was a vec4 gl_FragDatan. This was taken out since core OpenGL did not yet support multiple fragment color (or more generally, data) outputs.

Perhaps a simple extension to support this makes sense?

vec4 gl_FragDatanEXT?
Or
vec4 gl_FragDataEXT[n]?

(Where EXT is either a vendor extension affix, EXT affix, or if approved by the ARB, an ARB affix?)

-mr. bill

[Corrail]

Yes, I know that in original drafts there were more than one gl_FragColor. Hope they will extend GLslang soon!

According to the ARB notes from September it will be something like that :-)

vec4 EXT::gl_FragColorN;
or
vec4 EXT::gl_FragColor[N];

[cass]

Originally posted by Corrail:
Yes, I know that in original drafts there were more than one gl_FragColor. Hope they will extend GLslang soon!

According to the ARB notes from September it will be something like that :-)

vec4 EXT::gl_FragColorN;
or
vec4 EXT::gl_FragColor[N];

It seems kindof odd to combine "poor man's" scope resolution (gl_*) with first class scope resolution (EXT::*).

I think that

gl_FragColor_EXT[n]

or

gl_FragColorn_EXT

is more self-consistent. Of those two, I prefer the array notation, as it will more naturally extend to data-dependent draw buffer selection.

Thanks -
Cass

[mrbill]

Originally posted by cass:
It seems kindof odd to combine "poor man's" scope resolution (gl_*) with first class scope resolution (EXT::*).

I think that

gl_FragColor_EXT[n]

or

gl_FragColorn_EXT

is more self-consistent. Of those two, I prefer the array notation, as it will more naturally extend to data-dependent draw buffer selection.

Thanks -
Cass
I don't disagree with you with the EXT:: notation.

BUT....

It can't be gl_FragColor_EXT[n]. (Where EXT is either Vendor, EXT, or ARB.)

If such a name were to be promoted to core, it would then become:

gl_FragColor[n]

gl_FragColor[0] is the same as gl_FragColor.r, gl_FragColor[1] is the same as gl_FragColor.g, and so on....

gl_FragData_EXT[n] is fine though, since if promoted it becomes gl_FragData[n].

-mr. bill

[cass]

Bill,

D'oh! That was a copy-paste error on my part.

I meant gl_FragData*.

Thanks -
Cass