[Mesa-dev] Nuking GL_NV_vertex_program

Brian Paul brianp at vmware.com
Wed Oct 10 08:08:42 PDT 2012


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?

-Brian


More information about the mesa-dev mailing list