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.

Attachment: pgpxznqKAprwK.pgp
Description: PGP signature

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to