Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 7 of 7

Thread: GLSL and MRT

  1. #1

    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?

  2. #2
    Member Regular Contributor
    Join Date
    Apr 2002
    Location
    Austria
    Posts
    328

    Re: GLSL and MRT

    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...
    There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

    There is another theory which states that this has already happened...

  3. #3
    Intern Contributor
    Join Date
    Sep 2001
    Location
    Marlboro MA
    Posts
    90

    Re: GLSL and MRT

    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

  4. #4
    Member Regular Contributor
    Join Date
    Apr 2002
    Location
    Austria
    Posts
    328

    Re: GLSL and MRT

    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];
    There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

    There is another theory which states that this has already happened...

  5. #5
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: GLSL and MRT

    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
    Cass Everitt -- cass@xyzw.us

  6. #6
    Intern Contributor
    Join Date
    Sep 2001
    Location
    Marlboro MA
    Posts
    90

    Re: GLSL and MRT

    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

  7. #7
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: GLSL and MRT

    Bill,

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

    I meant gl_FragData*.

    Thanks -
    Cass
    Cass Everitt -- cass@xyzw.us

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •