Brian Paul <bri...@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.
pgpgw3AFEG79s.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
