Roland Scheidegger <srol...@vmware.com> writes: > Am 10.10.2012 17:48, schrieb Brian Paul: >> On 10/10/2012 08:34 AM, Roland Scheidegger wrote: >>> I think the idea of removing NV_vertex_program is quite good, though I >>> wonder if these functions shouldn't be renamed and moved instead of >>> keeping them as is? >>> Supporting both NV_vertex_program ARB_vertex_program always seems to >>> have caused headaches (not least because of the different aliasing of >>> attribs), though for a long time ARB_vertex_program in mesa actually was >>> code dependent quite a bit on NV_vertex_program. >>> IIRC celestia used to use NV_vertex_program but it's quite possible it >>> no longer does. >> >> I seem to recall testing Celestia with our VMware gallium driver in the >> past, and we've never supported GL_NV_vp/fp with gallium, so I think >> we're OK there too. > > Oh yes that was just an example of an app which could use it if > supported. But certainly not like viewperf it actually checked what's > available. I don't know if there was a version which only supported > NV_vp and not ARB_vp but even if there was that has to be decades ago...
Looking at the list of extensions it looks for, celestia also has ARB program and GLSL paths -- I assume when a program looks for those, they'll use those first, and nwn was the only candidate I knew of for NV_vp. I've got a repo of used extensions I've scraped at http://cgit.freedesktop.org/~anholt/gl-extension-list/ -- unfortunately with the popularity of GLEW and such the scraping rarely works on current apps.
pgpxznqKAprwK.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev