GLSL and MRT

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?

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…

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

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 :slight_smile:

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

Originally posted by Corrail:
[b]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 :slight_smile:

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

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

Originally posted by cass:
[b] 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[/b]

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

Bill,

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

I meant gl_FragData*.

Thanks -
Cass

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.