Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
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.
But couldn't you treat it as non-aliased, but compile a !!VP1.0 program so that references to "vertex.texcoord[0]" actually use "vertex.attrib[8]"? I don't really know NV_vertex_program, so that may be total nonsense.
I think that would be just too ugly/hackish to really consider.
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).
Right.
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.
So, new drivers that only support the ARB version would still have to hook into the old entry-points, right?
I think so. Going forward, glVertexAttrib4fvARB() and glVertexAttrib4fv() will implement non-aliasing behaviour. But glVertexAttrib4fvNV() must always implement aliasing.
If we do this in the drivers:
if (GL_NV_vertex_program is supported) {
table->VertexAttrib4fvNV = my_VertexAttrib4fvNV; // aliasing
}
else {
table->VertexAttrib4fvNV = my_VertexAttrib4fvARB; // no aliasing
}
table->VertexAttrib4fvARB = my_VertexAttrib4fvARB; // no aliasingI think we'll be OK, whether we have an old or new libGL.
-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
