[Piglit] [PATCH 1/6] shader_runner and glslparsertest: choose GL version more accurately.

[Paul Berry]

On 18 February 2013 11:50, Eric Anholt <eric at anholt.net> wrote:

> Paul Berry <stereotype441 at gmail.com> writes:
>
> > On 18 February 2013 07:53, Michel Dänzer <michel at daenzer.net> wrote:
> >
> >> On Don, 2013-02-14 at 08:50 -0800, Paul Berry wrote:
> >> > Previously, both shader_runner and glslparsertest contained switch
> >> > statements that attempted to choose a GL version for testing based on
> >> > a GLSL version requirement, and those switch statements didn't choose
> >> > a GL version very accurately (for example, they converted GLSL version
> >> > 1.50 to GL version 3.1, which doesn't work).
> >> >
> >> > This patch replaces the switch statements with a single common
> >> > function (in piglit-util-gl-common) that does the right thing.
> >>
> >> This change caused quick-driver.tests to skip more than 2000 tests on
> >> radeonsi (GL 2.1, GLSL 1.2). Almost all of the skipped tests were
> >> previously passing.
> >>
> >> Was this intended?
> >>
> >
> > No, this wasn't expected, and probably indicates a bug in the driver.
> >
> > The specific behavioural change in Piglit is that previously, when
> running
> > a test that required GLSL 1.20, Piglit would request (via Waffle) a GL
> 1.0
> > context.  Then it would query the context to see if it supported GLSL
> > 1.20.  After this patch, when running a test that requires GLSL 1.20,
> > Piglit requests a GL 2.1 context, and then skips if a GL 2.1 context
> can't
> > be created.  On an implementation that supports GL 2.1 and GLSL 1.20,
> both
> > methods should yield the same results.
>
> But what about an implementation that does GLSL 1.20 but not GL 2.1?  Or
> GLSL 1.30 but not all of GL 3.1?
>

I assume you meant to say "Or GLSL 1.30 but not all of GL 3.0?"  In other
words, you want to be able to test implementations that support a
higher-numbered GLSL version than what is required by the GL version that
they support.  I can definitely see the value in this, especially because
when we're developing support for the next version of GLSL in Mesa, we
often use MESA_GLSL_VERSION_OVERRIDE=xxx to switch on support for that GLSL
version, and it's nice to be able to do that without having to override the
GL version too.

On the other hand, I also want to be able to test implementations that
require core contexts in order to get at more recent GL/GLSL features (such
as Apple and Mesa/i965), as well as implementations that return only the
level of GL support that was requested (such as nVidia).  This is
especially important for the geometry shader tests I've just introduced,
because at the moment the only implementation available to me for
validating those tests is an nVidia system.

Unfortunately, it's impossible to meet all those requirements without a
more significant change to piglit.  Consider the case where we're tesitng
GLSL 1.50.  What type of context should Piglit attempt to create?

- If it attempts to create a GL 1.0 through GL 2.1 context, then the test
won't run on Apple, because we'll get a compatibility context, and Apple
doesn't support GLSL 1.50 with compatibility functionality.

- If it attempts to create a GL 1.0 through GL 3.0 context, then the test
won't run on Mesa/i965, because we'll get a compatibility context, and
we're not planning for Mesa/i965 to support GLSL 1.50 with compatibility
functionality.

- If it attempts to create a GL 1.1 through GL 3.1 context, then the test
won't run on nVidia, because on nVidia's implementation, if you request GL
version N, you get only the features required by GL version N and no
higher-numbered features.

- If it attempts to create a GL 3.2 context, then the test won't run on
implementations that support GLSL 1.50 but not GL 3.2.

Given that we have to sacrifice something, it seems to me that the least
bad alternative is to sacrifice implementations that support a higher GLSL
version than required by their GL version, because such an ability is rare
(outside our internal development of Mesa) and unlikely to be taken
advantage of by client programs.  The downside, of course, is that we have
to go some extra work when we're doing internal develpoment of a new GLSL
version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20130218/65739225/attachment.html>