[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36295

--- Comment #12 from José Fonseca <jfonseca at vmware.com> 2011-04-18 07:50:52 PDT ---
> (In reply to comment #2)
> Oh hell no.  Report this bug to spec.  Seriously.
>
> Issues of differing names of instance ID is one thing, but giant piles of
> functionality is completely different.  This is a MAJOR bug in viewperf.  It
> needs to be reported to them, and they need to fix it.  Period.

Even if viewperf fixes the extension detection, I don't think it will do much
for us or our users: Viewperf consists mostly of recorded GL calls. There is
likely no easy way to record the original Cg shaders and compile on demand for
the current hardware. So I think the inevitable outcome of fixing the extension
checks in viewperf is a error message saying "your graphics hardware isn't
capable enough" for all viewsets. This is, *Ii* they fix it, because I suspect
they probably won't bother given that AMD also silently handles it.

So, unless we provide the necessary functionality somehow, the last viewperf
Mesa based drivers will ever run will be SPECviewperf10.

Of course, instead of the simple hack to allow some NV_fragment_program2
opcodes, we could actually implement the whole NV_fragment_program2 and
NV_vertex_program2 extensions to the spec too. But I'm not very keen on
spending a bunch of time working on a non-ARB extension.

Personally I'd like to be able to test/benchmark Mesa with SPECviewperf11
somehow.

That said, as Brian said, it seems most of the corruption is not caused by
NV_fragment_program2 shader, but actually by NV_primtive_restart.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.