Compatibility state

Is there another document out besides http://www.opengl.org/registry/doc/GLSLangSpec.4.30.6.pdf that describes the uniforms of the compatibility Profile?
I do not find informations that would be necessary to duplicate the fixed-function functionality that the gl provides in the section about compatibility state variables.
At least quick-reading the document linked above as well as the gl-4.0 compatibility spec leave a lot of questions:
Where can be looked up if - for example - lighting is enabled for which lights (or are the Settings simply zeroed out?)?
Which variables hold Information about which texture target is bound to which texture unit? Where are the samplers?

Are those informations hidden in the documents and not listed in the summaries or aren’t they contained at all?

Look in section 7.5.1 of the GLSL 1.5 spec, it lists all the compatibility state. It hasn’t changed from 1.5 to 4.3, unless you’re using a core profile, in which case it’s been removed :slight_smile:

If you need to know the default settings, check out the man pages for various GL functions that set them (glLight, glMaterial, etc).

That really does not see different when compared to the document linked above. How can for example texture-mapping be applied using only the compatibility-state? It must be in there as open-gl 1.X can do texture mapping.

Texture mapping doesn’t have any built-in GLSL uniform compatibility state. You have to bind textures to units just as in the fixed function state. Then, assign the unit number to the uniform corresponding to the texture sampler in the shader, and then use a texture() method to sample the texture using that sampler.


   // program:
   glUseProgram( prog_id );
   glUniform1i("diffuse_tex", 0);
   glActiveTexture(0);
   glBindTexture( GL_TEXTURE_2D, diffTex );

   // shader:
   uniform sampler2D diffuse_tex;

   void main()
   {
        vec4 col;
        vec2 texcoord;
        texcoord =  [tex coords from vertex shader, likely];
        col = texture( diffuse_tex, texcoord);
   }

That’s what I read from the spec. And I wonder about it. The compatibility-profile-state should encompass any state-variable that is needed to achieve the functionality described by the opengl-legacy functions: One cannot replace the default-functionality-shaders without loss of functionality with only the Information given in the profile-spec.

What kind of texturing are you trying to do? I haven’t run into a situation where I wasn’t able to do something in shaders that fixed function could do. I make my own uniforms and pass the information I need to the shader through them (such as ‘uniform int enable_diffuse_map’). Some of the old texture environment is convenient, but fairly straightforward to code in a shader. Plus you get a lot more flexibility than the old texture combiners.

For example if I want to Exchange the underlying vertex- and Fragment-processing of a program that was written for the legacy functionality. It uses texture-mapping and all other kinds of functionality but does NOT use shaders of any kind. That should be possible without losing any functionality.
EDIT: I do not need any help implementing texture-mapping etc. in shaders using the functionality in place in the newer Versions. It is I am confused over the specification of the compat-profile. A program using legacy-functionality that is worked on cannot easily replace old fixed-functionality in parts with the Profile as it seems. That would be a lousy specification. It should be possible to write shaders that duplicate the fixed-functionality of OpenGL in a 1:1 Fashion and do not Need any changes in the application code.

My shot-in-the-dark guess is the the texture state isn’t part of the GLSL uniform state because it was either too complex or no one used it.

Is there another document out besides http://www.opengl.org/registry/doc/G...pec.4.30.6.pdf that describes the uniforms of the compatibility Profile?

That’s the GLSL specification. This defines what GLSL is; if it’s not in there, it doesn’t exist (or there’s a spec bug).

It should be possible to write shaders that duplicate the fixed-functionality of OpenGL in a 1:1 Fashion and do not Need any changes in the application code.

What you’re talking about is the glTexEnv state. That’s not available because what you’re wanting to do is not what the compatibility stuff is for.

The purpose of the compatibility state tracking is to allow users to slowly transition part of their code to the new methodology. It was never the intent to be able to do so with no changes, only relatively few. glTexEnv, for example, is considered too intimately associated with the fragment processing scheme to use. Plus, back when people actually used the state tracking stuff, you would have to have a fragment shader that looked like this:


vec4 texVal0 = texture2D(tex0, gl_MultiTexCoord[0]);
if(gl_TexEnv[0].func == gl_TexEnvCombine)
{
}
else if(gl_TexEnv[0].func == gl_TexEnvADD)
{
}
...

This could would be unacceptably slow on modern machines. On machines of the GL 2.0 era, it simply wouldn’t compile.

glTexEnv is the equivalent to modifying your shader’s source code, not merely setting a parameter. Thus, it’s state is not tracked.

When talking about the compatibility-profile I would not care about performance issues when it comes down to mimique all defined behaviour in a shader. I would merely point out that the compatibility-state-variables should expose enough information to theoretically replace all defined fixed-pipeline-behaviour with shaders that do the same stuff.
This is where I do not get your reading

The purpose of the compatibility state tracking is to allow users to slowly transition part of their code to the new methodology.

Having informations about which texture-units are enabled, exposing sampler variables for these unit, informations about lights that are enabled, all that are things I would have expected to be in the profile. WIth that information one can easily
precede blocks of legacy-rendering code with a useProgram-statement and maybe enhance the visual-experience.
I really do not know what the big point of the core-profile is. If an attribute is specifed with vertexAttrib or texCoord and thus named myVertexAttrib or gl_MultiTexCoords in the shader - what is the big difference? If you had to state the core principles of the new methodology, what would it be?
This is why I would call

It was never the intent to be able to do so with no changes, only relatively few.

that a poor design decision.

I really do not know what the big point of the core-profile is. If an attribute is specifed with vertexAttrib or texCoord and thus named myVertexAttrib or gl_MultiTexCoords in the shader - what is the big difference?

Well, let’s ignore the obvious points of having a variable name that actually describes the contents of its data, instead of pretending gl_MultiTexCoord3 really means “matrix bone weights”. Let’s look at purely practical issues: things you cannot do with compatibility attributes.

Non-generic vertex attributes cannot:

1: Be integer or double-precision. gl_Vertex is, and always will be, a vec4. Not an ivec4 or dvec4.

2: Use more resources than specified. There are exactly and only 8 texture coordinates, one position, two colors, one normal, and a single floating-point fog coordinate. If you happen to need more per-vertex attributes than that, tough. Even if your hardware could provide more of them, you can’t use them.

3: Use the new split-format syntax.

4: Use instanced arrays.

And this is just for attributes.

The “big point of the core-profile” is to define a reasonable API that doesn’t include superfluous cruft. Like gl_Vertex. Generic vertex attributes are the more flexible mechanism, so they are the only mechanism. Shaders are the more flexible mechanism for doing various processing, so they are the only mechanism. And so forth.

The only fixed-function stuff left are things that need to be due to being connected to fixed processing stages. gl_Position as an output from the vertex processing is there because there needs to be some way for a shader to say, “This is the clip-space position of the vertex, go use that in the primitive.” gl_FragDepth is there as a fragment shader output because it has very specific meaning for the depth test. And so forth.

Core OpenGL is a cleaner, more focused API that doesn’t have as much redundancy in it. Though thanks to that split-format syntax, we’re getting new redundancy…

This is why I would call

[quote]It was never the intent to be able to do so with no changes, only relatively few.

that a poor design decision. [/quote]

Well, to me, the compatibility profile itself is a poor design and should never have been brought back in GL 3.2. So it’s a matter of personal taste.

But as I pointed out earlier, what you wanted to write would never have compiled on most hardware of the day when this system was devised. It simply would not have been possible for hardware to run such things. And nowadays, most people don’t need the GLSL-to-fixed-function interop code. So even now when you could write it, you wouldn’t.

The ARB is not going to create a new feature solely for compatibility OpenGL. While they do keep it up-to-date to some extent, many features (like split-format syntax) don’t get back-ported to the old stuff (one of the only useful side-effects of deprecation&removal is that they don’t add functions solely for compatibility GL anymore). And unless a new feature brings something to core OpenGL, it’s highly unlikely they’ll bother with it.

I should not have come up with vertex-attribute I see. My Point was simply the following: Trying to enhance old gl-code is easy and can be done in a smooth fade up to a certain point when suddenly a large portion of application code Needs to be changed or the whole OpenGL-api has to be hooked to keep track of the state changes - not only the functions that got thrown out of the core Profile.

or the whole OpenGL-api has to be hooked to keep track of the state changes

No, only glTexEnv and texture enable state needs to be tracked. Everything else is tracked for you.

not only the functions that got thrown out of the core Profile.

What core functions need state tracking? I certainly don’t need it.

And why aren’t those tracked for compatibility?

I told you why: tracking it would have been pointless. In the GL 2.0 days, hardware would not have been able to compile code like that. And now that hardware can, nobody actually wants to do it or needs the functionality.

! …

I think you are missing a big point that Alfonse is trying to make: glTexEnv changes are akin to changing what fragment shader is run. The entire multi-texturing API was for the pre-shader age. glTexEnv is a great deal clunkier to do that a fragment shader (and for that matter glTexGen is a great deal clunkier than writing a vertex shader).

My suggestion: Let the compatibility profile go.

Have you looked at Regal?

https://github.com/p3/regal

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