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
