[Mesa-dev] Nuking GL_NV_vertex_program

[Eric Anholt]

Brian Paul <brianp at vmware.com> writes:

> On 10/10/2012 09:08 AM, Brian Paul wrote:
>> On 10/10/2012 08:59 AM, Kenneth Graunke wrote:
>>> On 10/10/2012 07:42 AM, Jose Fonseca wrote:
>>>> I think certain versions of SPEC viewperf rely on NV_vertex_program.
>>>> See http://www.mesa3d.org/viewperf.html
>>>>
>>>> We had some internal hacks to support just the bare minimum of to
>>>> run some of these tests, but they were not accepted on mesa proper.
>>>> (There is some bug report on fdo about it).
>>>>
>>>> Jose
>>>
>>> Ugh. I'd forgotten about SPECviewperf.
>>>
>>> I guess this begs the question: do we care?
>>>
>>> According to that page, viewperf11 is a buggy application (using
>>> extensions without checking for them), and to get it working properly,
>>> we'd need to implement two more legacy extensions that aren't
>>> necessary for anything else. Or add the minimum required and driconf
>>> workarounds to falsely advertise them.
>>>
>>> In my experience, viewperf is extremely frustrating to work with and
>>> isn't useful for testing either correctness nor performance. The only
>>> reason anyone appears to care is that it's some kind of "industry
>>> standard" benchmark. These days, however, it seems more people care
>>> about glbenchmark.com's benchmarks, 3DMarkMobileES 2.0, and various
>>> games. At least on my team, no one is measuring us against
>>> SPECviewperf.
>>>
>>> Do people still care about viewperf on your side?
>>
>> Unfortunately, the people that review VMware's products (Workstation,
>> Fusion, etc) often run Viewperf and we've been dinged by reviewers
>> when they find issues with it. Part of the motivation for creating
>> http://www.mesa3d.org/viewperf.html was to educate reviewers about the
>> issues with Viewperf 11.
>>
>> I've reported the VP11 issues to SPEC and was told that they'd be
>> addressed for Viewperf 12. Unfortunately, there's no way for the
>> public to review/test VP12 before it's released (at least not without
>> paying a very hefty membership fee) so we have to just cross our
>> fingers that VP12 will be better implemented than VP11.
>>
>> Can we please hold off on this change for just a bit while we review
>> the situation?
>
> OK, I think it's good news.
>
> I hadn't looked at VP in a while but it looks like all the 
> vertex/fragment programs are actually of the ARB variety, not the NV 
> variety.
>
> The catia-03 test uses GL_NV_fragment_program2 and 
> GL_NV_vertex_program3 (without checking if they're actually 
> supported!) but those extensions are layered on 
> GL_ARB_vertex/fragment_program, not GL_NV_vertex/fragment_program.
>
> The VP source code definitely has calls to glProgramStringARB() but I 
> don't see any calls to glLoadProgramNV() which is what NV programs use.
>
> So, I think we're OK with viewperf.
>
> I'll do a review of Eric's patches too...

Oh, I'd forgotten that the later NV_vps were layered on ARB_vp.  There's
a late patch in the series we might want to drop.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20121010/b3329eb5/attachment.pgp>