Both patches are Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
Please send a 3rd with switch statements. :-) Or, you can rev this patch. I don't care. --Jason On Tue, Aug 28, 2018 at 5:13 PM Ian Romanick <i...@freedesktop.org> wrote: > From: Ian Romanick <ian.d.roman...@intel.com> > > The negative tests in this group require some inference from various > specs. A spec bug has been submitted against the > GL_ARB_fragment_shader_interlock spec. > > Currently none of the negative tests produce the expected result on > Mesa. > > Signed-off-by: Ian Romanick <ian.d.roman...@intel.com> > --- > .../beginInvocationInterlock-after-discard.frag | 27 +++++++++++ > .../beginInvocationInterlock-after-return.frag | 51 > +++++++++++++++++++++ > .../beginInvocationInterlock-inside-do-while.frag | 49 > ++++++++++++++++++++ > .../beginInvocationInterlock-inside-for.frag | 50 > +++++++++++++++++++++ > .../beginInvocationInterlock-inside-if.frag | 48 > ++++++++++++++++++++ > ...vocationInterlock-inside-non-main-function.frag | 51 > +++++++++++++++++++++ > .../beginInvocationInterlock-inside-while.frag | 49 > ++++++++++++++++++++ > .../endInvocationInterlock-after-discard.frag | 28 ++++++++++++ > .../endInvocationInterlock-after-return.frag | 52 > ++++++++++++++++++++++ > .../endInvocationInterlock-inside-do-while.frag | 49 > ++++++++++++++++++++ > .../endInvocationInterlock-inside-for.frag | 50 > +++++++++++++++++++++ > .../compiler/endInvocationInterlock-inside-if.frag | 48 > ++++++++++++++++++++ > ...vocationInterlock-inside-non-main-function.frag | 51 > +++++++++++++++++++++ > .../endInvocationInterlock-inside-while.frag | 50 > +++++++++++++++++++++ > 14 files changed, 653 insertions(+) > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag > create mode 100644 > tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag > > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag > new file mode 100644 > index 000000000..1c74fa49c > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-discard.frag > @@ -0,0 +1,27 @@ > +// [config] > +// expect_result: pass > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +in float f; > + > +void main() > +{ > + if (f < 0.5) > + discard; > + > + beginInvocationInterlockARB(); > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag > new file mode 100644 > index 000000000..29493ff9e > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-after-return.frag > @@ -0,0 +1,51 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +uniform bool condition; > + > +void main() > +{ > + if (condition) > + return; > + > + beginInvocationInterlockARB(); > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag > new file mode 100644 > index 000000000..f68d7936a > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-do-while.frag > @@ -0,0 +1,49 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + do { > + beginInvocationInterlockARB(); > + } while (false); > + > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag > new file mode 100644 > index 000000000..2ca54bc8a > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-for.frag > @@ -0,0 +1,50 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + for (;;) { > + beginInvocationInterlockARB(); > + break; > + } > + > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag > new file mode 100644 > index 000000000..53fe7e7d9 > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-if.frag > @@ -0,0 +1,48 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + if (true) > + beginInvocationInterlockARB(); > + > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag > new file mode 100644 > index 000000000..63c1c6c4b > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-non-main-function.frag > @@ -0,0 +1,51 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void wrapper() > +{ > + beginInvocationInterlockARB(); > +} > + > +void main() > +{ > + wrapper(); > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag > new file mode 100644 > index 000000000..6283c5ef7 > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-while.frag > @@ -0,0 +1,49 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * A compile- or link-time error will be generated if main() calls > either > + * function more than once, contains a call to one function without a > + * matching call to the other, or calls endInvocationInterlockARB() > before > + * calling beginInvocationInterlockARB(). > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > functions > + * delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + while (true) { > + beginInvocationInterlockARB(); > + break; > + } > + > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag > new file mode 100644 > index 000000000..82344231d > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-discard.frag > @@ -0,0 +1,28 @@ > +// [config] > +// expect_result: pass > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +in float f; > + > +void main() > +{ > + beginInvocationInterlockARB(); > + > + if (f < 0.5) > + discard; > + > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag > new file mode 100644 > index 000000000..83fcaf47a > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-after-return.frag > @@ -0,0 +1,52 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +uniform bool condition; > + > +void main() > +{ > + beginInvocationInterlockARB(); > + > + if (condition) > + return; > + > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag > new file mode 100644 > index 000000000..8875e1ff7 > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-do-while.frag > @@ -0,0 +1,49 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + beginInvocationInterlockARB(); > + > + do { > + endInvocationInterlockARB(); > + } while (false); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag > new file mode 100644 > index 000000000..468054fbf > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-for.frag > @@ -0,0 +1,50 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + beginInvocationInterlockARB(); > + > + for (;;) { > + endInvocationInterlockARB(); > + break; > + } > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag > new file mode 100644 > index 000000000..648f10709 > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-if.frag > @@ -0,0 +1,48 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + beginInvocationInterlockARB(); > + > + if (true) > + endInvocationInterlockARB(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag > new file mode 100644 > index 000000000..0d34cb765 > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-non-main-function.frag > @@ -0,0 +1,51 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void wrapper() > +{ > + endInvocationInterlockARB(); > +} > + > +void main() > +{ > + beginInvocationInterlockARB(); > + wrapper(); > +} > diff --git > a/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag > new file mode 100644 > index 000000000..9b3fc424d > --- /dev/null > +++ > b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-while.frag > @@ -0,0 +1,50 @@ > +// [config] > +// expect_result: fail > +// glsl_version: 4.20 > +// require_extensions: GL_ARB_fragment_shader_interlock > +// check_link: false > +// [end config] > + > +/* The GL_ARB_fragment_shader_interlock spec says: > + * > + * The beginInvocationInterlockARB() and endInvocationInterlockARB() > may > + * only be placed inside the function main() of a fragment shader and > may > + * not be called within any flow control. These functions may not be > + * called after a return statement in the function main(), but may be > + * called after a discard statement. > + * > + * and > + * > + * (8) What restrictions should be imposed on the use of the > + * beginInvocationInterlockARB() and endInvocationInterlockARB() > + * functions delimiting a critical section? > + * > + * RESOLVED: We impose restrictions similar to those on the > barrier() > + * built-in function in tessellation control shaders to ensure that > any > + * shader using this functionality has a single critical section > that can > + * be easily identified during compilation... > + * > + * The GLSL 4.60 spec says: > + * > + * For tessellation control shaders, the barrier() function may only be > + * placed inside the function main() of the tessellation control > shader and > + * may not be called within any control flow. Barriers are also > disallowed > + * after a return statement in the function main(). Any such misplaced > + * barriers result in a compile-time error. > + * > + * From this we infer that the first errors mentioned in the > + * GL_ARB_fragment_shader_interlock spec are intended to generate > compile-time > + * errors. > + */ > +#version 420 > +#extension GL_ARB_fragment_shader_interlock: require > + > +void main() > +{ > + beginInvocationInterlockARB(); > + > + while (true) { > + endInvocationInterlockARB(); > + break; > + } > +} > -- > 2.14.4 > > _______________________________________________ > Piglit mailing list > Piglit@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/piglit >
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit