-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDSpqNX1gOwKyEAw8RAhpVAKCRU4+Jyo3iPelkgRUlyoZBfjr7TgCffLlI VXp8qXoCR+s33YhI/XJ8sNo= =BG9w -----END PGP SIGNATURE----- ------------------------------------------------------- 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
