Brian Paul wrote:
As someone mentioned before, in OpenGL 2.0 generic attributes (set by calling glVertexAttrib) do not alias with conventional attributes. This conflicts with GL_NV_vertex_program and changes the policy defined in GL_ARB_vertex_program (where aliasing was optional).
The GL_ARB_vertex_shader extension (and hence, 2.0) says that GL_ARB_vertex_program is retro-modified such that vertex attribute aliasing no longer occurs. That means the glVertexAttrib*() functions must work identically to the glVertexAttrib*ARB() functions.
I want to make sure I understand this correctly. The aliasing issue is whether or not glVertexAttrib3fvARB( 0, v ) and glVertex3fv( v ) modify the same state, right?
Well, attribute 0 is _always_ the vertex position and triggers vertex transformation, regardless of the aliasing policy. A better example is to ask if glTexCoord4fv(v) and glVertexAttrib4fv(8,v) set the same state.
If vertex attributes are aliased, the commands are equivalent.
If vertex attributes are not aliased, they set different state.
Unfortunately, the GLX protocol and Mesa/libGL dispatch table already have aliasing between glVertexAttrib*ARB and glVertexAttrib*NV. The later functions *must* implement attribute aliasing.
This is a big problem.
Yeah, it is. :(
It looks like the only way to tell the difference between the two extensions is "!!ARBvp1.0" vs. "!!VP1.0" in the program text. I suppose we could track the glVertexAttrib3fvARB as non-aliased, but compile a !!VP1.0 program to use the attribs in place of the conventional attribs. That is, we'd take care of it at the compiler level instead of at the GL state level. It would be messy, though.
I don't think you can determine the behaviour of glVertexAttrib*ARB at runtime by looking at the currently bound program. There may not be any currently bound program when the vertex attrib command is called. I could name any number of gotcha's with that approach.
It seems to me that we have no choice but to change the GLX protocol and libGL dispatch table to undo the aliasing between the ARB and NV functions. This will, of course, introduce an interface incompatibility.
I'm going to ask someone at NVIDIA for their opinion on this. But if anyone else has any ideas how to handle this, I'd love to hear it.
Since nobody has implemented the GLX protocol, that part won't be too problematic. The problem is with the dispatch tables. I'm not even sure that would be that much of a problem to change. Afterall, the code that vectors through the dispatch table is dynamically linked, so no application should break.
I'm thinking the "NV" entrypoint would remain at their present dispatch offsets (and keep their GLX opcodes) while the "ARB" entrypoints would be given new dispatch offsets (and new GLX opcodes).
In that case, a call to glVertexAttrib4fvARB(8, v) would either set texcoord 0 or the 8th generic attribute, depending on whether the app linked with an old or new libGL.
Luckily, this apparent inconsistency is allowed by the original GL_ARB_vertex_program extension (aliasing is optional). This might not be so bad afterall. Of course, there's a few other commands such as glGetVertexAttrib*ARB to be considered.
The only drivers that would have problems would be any that support both NV_vertex_program and ARB_vertex_program. That would only be a problem is you mixed a new libGL with an old driver. I think the *only* driver that has been official release that would hit this is the i915 driver in Xorg 6.8.0, right? I think the exposure is limited enough that we should just do it.
There's an OpenGL ARB meeting next week that I'm planning on attending. Perhaps I can write up the issues and get the ARB to vote on a GLX spec change.
-Brian
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
