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?
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.
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.
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.
-------------------------------------------------------
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
