<div dir="ltr"><div>Both patches are</div><div> </div><div>Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>></div><div> </div><div>Please send a 3rd with switch statements. :-) Or, you can rev this patch. I don't care. </div><div> </div><div>--Jason </div></div> <div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 5:13 PM Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.com</a>> 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 <<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.com</a>> --- .../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 <a href="mailto:Piglit@lists.freedesktop.org" target="_blank">Piglit@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/piglit" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/piglit</a> </blockquote></div>