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

[Paul Berry]

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

> Paul Berry <stereotype441 at gmail.com> writes:
>
> > 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.
>
> The thing I'd prefer to sacrifice is testing of closed source drivers --
> piglit is a tool for Mesa development, and we should prefer testing Mesa
> over testing other things.  If hacks are needed for developing tests on
> other drivers first, do so locally, but don't regress Mesa testing.
>

I was initially skeptical about this, but I may be coming around.  A few
days ago I thought that supporting a higher GLSL version than required by
the GL version was limited to internal Mesa development, but I've since
learned that (a) softpipe supports GL 2.1 and GLSL 1.30, and (b) it's been
suggested that adding GLSL 1.30 support to i965 Gen5 might be sufficient to
address https://bugs.freedesktop.org/show_bug.cgi?id=59187.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20130220/8a1ff238/attachment-0001.html>