Ian Romanick wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Roland Scheidegger wrote:
Philipp Klaus Krause wrote:
3) It is a widespread extension, not a Nvidia-specific one: It is
implemented by the i915 driver, the mga driver, the tdfx driver, the
r300 driver, the non-free 3Dlabs drivers and
of course all the Nvidia drivers.
It's not completely limited to nvidia hardware, but it's still a
non-standard extension. If you look at commercial drivers
(www.delphi3d.net), support is indeed pretty much limited to nvidia
hardware, the only other company to support it is 3dlabs - no ATI, no
intel, no matrox, nothing. That is quite nvidia-specific if you ask me.
For all practical purposes, NV_vertex_program is dead. The only
non-open-source drivers on *any* platform that support it *today* are
Nvidia's. 3dlabs used to support it, but I believe they dropped support
for it as soon as GLSL became available. Modern Nvidia vertex program
extensions (e.g., GL_NV_vertex_program3) are layered on the ARB
extension instead of the old NV extension.
4) I added an option to deactivate it.
Makes the driver even more complex :-).
btw it looks you can't announce ARB_vertex_program on r128. The
extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3.
Not sure why exactly, there doesn't seem to be anything in the new
features of OpenGL 1.3 which seems to be related to vertices (safe maybe
multitexturing, or maybe matrix transpose, I didn't study the extension
to see if you could do it with 1.2 + multitexture). NV_vertex_program
requires only 1.2.1 though.
I looked into this a bit. I don't see *anything* in the ARB_vp spec
that requires OpenGL 1.3. I can't see any reason to not expose it even
on lesser hardware.
Here's my opinion on the matter, but I'd like to hear from Brian or Keith.
1. All drivers should expose GL_ARB_vertex_program and
GL_MESA_program_debug. I don't care either way about the NV extensions.
2. There should be a single option to disable all software vertex
program extensions.
3. If vertex programs are too slow to be usable (and they are), we
should fix that.
4. We should work towards getting GL_NV_vertex_program2_option and
GL_NV_vertex_program3 supported. That should give us all the low-level
infrastructure that we need to support GLSL vertex shaders.
Items #1 and #2 could be handled for all drivers by a routine in
src/mesa/drivers/dri/common/utils.c. Something like
driEnableVertexProgramExtensions(GLcontext *ctx, driOptionCache
*options) should do the trick.
Looking into my OpenGL crystal ball, my guess is that the next major
version of OpenGL (i.e., 3.0) will take the same route as OpenGL ES 2.0:
all fixed function paths will be eliminated. I, for one, am tired of
carrying around the dead weight of optimized fixed function paths. I
would be tickled pink to have fixed function state tracking pulled into
a layered library that sliently generates GLSL programs for the application.
I don't have any problems with any of that.
-Brian
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
