On Thu, Jun 19, 2014 at 6:45 AM, Francisco Jerez <[email protected]> wrote: > Ilia Mirkin <[email protected]> writes: > >> --- >> >> Not actually an issue on the blob, since it supports ARB_geometry_shader4, >> but >> Chris Forbes pointed it out. This also works. >> >> tests/spec/arb_shader_atomic_counters/common.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tests/spec/arb_shader_atomic_counters/common.c >> b/tests/spec/arb_shader_atomic_counters/common.c >> index 7547d5d..95d809e 100644 >> --- a/tests/spec/arb_shader_atomic_counters/common.c >> +++ b/tests/spec/arb_shader_atomic_counters/common.c >> @@ -211,7 +211,7 @@ atomic_counters_supported(GLenum shader_stage) >> return n; >> >> case GL_GEOMETRY_SHADER: >> - if >> (piglit_is_extension_supported("GL_ARB_geometry_shader4")) >> + if (piglit_get_gl_version() >= 32) > > Wouldn't this do the wrong thing on e.g. an implementation of GL3.1 that > exposes ARB_geometry_shader4?
Not really. The rest of the code expects the GL3.2 GS, not the ARB_geometry_shader4 one. For example, I moved to using #version 150, and there are no ARB_geometry_shader4 enables. This seemed like the right move since mesa isn't going to get ARB_gs4 anytime soon, and all reasonable impls that have atomic counters would also have GL3.2. Such a hypothetical implementation could be supported by conditionally using version 140/ARB_gs4. When one finds such an implementation (GL3.1 only, ARB_gs4, AND atomic counters), and wants to run piglit against it, they'll have to fix up the test. -ilia _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
