diff options
author | Ian Romanick <ian.d.romanick@intel.com> | 2018-08-28 15:08:35 -0700 |
---|---|---|
committer | Ian Romanick <ian.d.romanick@intel.com> | 2018-08-29 18:36:40 -0700 |
commit | 47af7fcad070c755327cd3a075a8cbc524f4d37d (patch) | |
tree | 96dd340f881dae1de0577f72cbff97914c944878 /tests/spec | |
parent | 3fb217de1f30c7fc2553d9f32979a887bea33a3a (diff) |
arb_fragment_shader_interlock: Additional compile tests
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.
v2: Add test for switch-statements. Noticed by Jason.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Diffstat (limited to 'tests/spec')
16 files changed, 761 insertions, 0 deletions
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-switch.frag b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-switch.frag new file mode 100644 index 000000000..2b982b1f4 --- /dev/null +++ b/tests/spec/arb_fragment_shader_interlock/compiler/beginInvocationInterlock-inside-switch.frag @@ -0,0 +1,54 @@ +// [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 int c; + +void main() +{ + switch (c) { + case 0: + default: + beginInvocationInterlockARB(); + break; + } + + 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-switch.frag b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-switch.frag new file mode 100644 index 000000000..5c63967cd --- /dev/null +++ b/tests/spec/arb_fragment_shader_interlock/compiler/endInvocationInterlock-inside-switch.frag @@ -0,0 +1,54 @@ +// [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 int c; + +void main() +{ + beginInvocationInterlockARB(); + + switch (c) { + case 0: + default: + endInvocationInterlockARB(); + break; + } +} 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; + } +} |