[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Apr 19 17:21:47 PDT 2011
https://bugs.freedesktop.org/show_bug.cgi?id=36295
--- Comment #15 from Ian Romanick <idr at freedesktop.org> 2011-04-19 17:21:46 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > The downside is that app developers never fix *THEIR* bugs.
> >
> [...]
> >
> > And this is the disaster that we're trying to fix via conformance testing.
> > This crap has to STOP. This is why people think OpenGL is joke.
>
> (This is slightly OT, but I'd argue that the OpenGL problem is not that spec
> conformance per se, but the proliferation of vendor specific extensions, and
> extensions in general; and the fix is not conformance testing but the ARB
> ratifying the extensions people care and lumping extensions in core versions.
> It looks things are moving on the right direction. That said, latest core
> version is 4.0 and we're still in 2.1, so I'm thankful for extensions that get
> us half way there.)
>
> Anyway, Ian, I see you strongly feel against the proposed patch, but I still am
> not sure exactly what you oppose: diverging the spec, or adding the extensions
> to meet an application's requirement? That is, would fully implementing
> NV_fragment_program2 to the spec and advertising it for SPECviewperf11's sake
> be OK with you or not, and why?
I don't care too much what extensions we decide to support. We already support
most of NV_fragment_program2. The primary missing bits are support for clip
distance, and we need to add that for GLSL 1.30 anyway. I don't recall if the
rest of the support is in master or on an old, dusty branch. It might be one
one of my asm-shader-rework branches...
I am strongly opposed to allowing an application to use functionality that is
not advertised or, in the case of GLSL extensions, not enabled because it
prevents us from removing those features in the future. Over the last 18
months we've removed a lot of old extensions that we did not want the on going
burden of supporting. I fully expect that we will do more of this in the
future. When applications either gracefully don't work or fallback to
different rendering paths, this is fine. When apps start to explode, it's not
fine. When we let applications use undocumented features or use documented
features in illegal ways, we paint ourselves into a corner. We effectively
trade short-term gain for long-term pain.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the mesa-dev
mailing list