<div dir="ltr">On 20 February 2013 11:32, Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>> wrote: <div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class=""><div class="h5">Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> writes: > On 18 February 2013 11:50, Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: > >> Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> writes: >> >> > On 18 February 2013 07:53, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> 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. </div></div>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. </blockquote></div> </div><div class="gmail_extra">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 <a href="https://bugs.freedesktop.org/show_bug.cgi?id=59187">https://bugs.freedesktop.org/show_bug.cgi?id=59187</a>. </div></div>