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