[Piglit] [PATCH 2/2] arb_fragment_shader_interlock: Additional compile tests
Jason Ekstrand
jason at jlekstrand.net
Tue Aug 28 22:28:48 UTC 2018
Both patches are
Reviewed-by: Jason Ekstrand <jason at jlekstrand.net>
Please send a 3rd with switch statements. :-) Or, you can rev this patch.
I don't care.
--Jason
On Tue, Aug 28, 2018 at 5:13 PM Ian Romanick <idr at freedesktop.org> wrote:
> From: Ian Romanick <ian.d.romanick at 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.romanick at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/piglit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/piglit/attachments/20180828/bc381035/attachment-0001.html>
More information about the Piglit
mailing list