Getting list of frag data output names

Hi guys !
I’ve read through the OpenGL 3.0 spec but I can’t find a way to query a program object for its output frag data list (output from a fragment shader to be written in bound draw buffers). One can use glGetFragDataLocation but this assumes that you know the name of the ouptut.

If it’s not possible why is it possible to query uniform and attribute list but not frag data output list ?

Thanks.

Are you saying you want to be able to query which of the following are written to by the compiled/linked fragment shader in a program object?:

  • gl_FragColor
  • gl_FragData[1,2,…]
  • gl_FragDepth

If so, this is probably best asked in the GLSL forum.

If it’s not possible why is it possible to query uniform and attribute list but not frag data output list ?

Don’t know for sure that it isn’t possible, but uniforms/attributes have to be provided for the shader to work properly. However, whether or not you use all the outputs is up to you. Can definitely see your point though.

Thanks Dark Photon,

Are you saying you want to be able to query which of the following are written to by the compiled/linked fragment shader in a program object?:

Yes but not just for gl_Color / gl_FragData (as they’re deprecated with 3.1). Now we can use any variable name for fragment output, something like this is a valid fragment shader source (from what i’ve read in the spec) :


#version 140
out vec3 worlNormal;
out vec3 worldPosition;

void main() {
    worldNormal = fancy_computation1();
    worldPosition = fancy_computation2();
}

What I couldn’t find is something like an equivalent to glGetActiveUniform but for variables written by the fragment shader. The same function exists for vertex attributes with glGetActiveAttrib. So what about fragment shader output ?

There’s an equivalent to glGetUniformLocation, it’s glGetFragDataLocation but here, one has to know the name of the fragment shader variable to query it’s location (as opposed to uniform data where such variable names can be queried with getGetActiveUniform).

Same problem !

Is there any answer ?

Looks like an oversight by the ARB.

Oversight?
There’s glGetShaderSource() and a grammar provided at the back of the GLSL spec.
:wink:

Hello,

I’m resurrecting this old thread because I’m looking for the same thing and don’t see that this got solved yet but maybe I’m wrong.

So I need something like:


glGetProgramiv( progName, GL_ACTIVE_FRAGDATA, &outPutCount );
glGetProgramiv( progName, GL_ACTIVE_FRAGDAT_MAX_LENGTH,  &longestFragDataName );

for (int i = 0; i < outPutCount; ++i) {
    glGetActiveFragData( progName, i, ... , name );
}

To query all names and with those later on the locations of fragment shader outputs.

Is there currently no alternative to parsing the sourcecode and assuming all outs are active?

No; the ARB hasn’t bothered correcting this oversight. I would suggest using the suggestions forum. Just don’t get your hopes up; it took them well over half a decade to add separable programs and the ability to specify attribute locations/fragment output locations/texture units in the shader file itself (stuff HLSL had from day 1).

I wouldn’t hold my breath.

I’ve filed a bug on it. Granted, considering how many bugs are on the site that haven’t been taken care of (even basic maintenance of the bug DB doesn’t seem to happen), that seems unlikely.

Thank you Alfonse.

So right now I guess I only have two options:

  • parse the shader sources correcty.
  • parse the sources roughly to get tokens that could be out valiables (possibly with false positives) and stuff them into glGetFragDataLocation to check which don’t return -1.

But I guess with binary shaders I wouldn’t have any chance to get the desired information :frowning:

You don’t need to fully parse GLSL. You just need the global definitions. If you see uniform or in, then you keep going until you get to a semicolon (ignoring comments) and start again. If you see out, then you know you’re dealing with an output variable. If you see a function definition, then just swallow while counting { and } until you’re through it.

It shouldn’t be that hard. It’s non-trivial, but not too tough.

In 99% of the cases it wouldn’t be hard, but then there are comments (out vec4 /foo/bar), marcos (#define X foo … out vec4 X;) and macro concatenation (#define NAME vTex ## Coord … out vec4 NAME; )…
It looks to stupid to figure out the variable names if the OpenGL implementation has the list already but is lacking API (while uniform and attribute names can be queried).

Guess I will write a parser that ignores the obscure cases. Might be a good reason to play around with the C++11 regex classes.

There’s a freely available GLSL parsing library by 3DLabs, google for “GLSLValidate”. However it is no longer updated (IIRC only supports up to GLSL1.x) but might be useful. I have used it before, and didn’t noticably conflict with GL2.x GLSL functionality.

The 3DLabs library almost certainly wasn’t kept up to date for GLSL 1.30 and above. Since 3D Labs kinda died.