[Piglit] [PATCH 2/3] GS: Tests that varying arrays can only be passed between VS and GS within blocks
Paul Berry
stereotype441 at gmail.com
Mon Sep 16 09:52:29 PDT 2013
On 16 September 2013 09:43, Paul Berry <stereotype441 at gmail.com> wrote:
> On 12 September 2013 10:47, Nicholas Mack <nichmack at gmail.com> wrote:
>
>> ---
>> .../execution/vs-gs-arrays-fail.shader_test | 63 ++++++++++++++++
>> .../vs-gs-arrays-within-blocks-pass.shader_test | 86
>> ++++++++++++++++++++++
>> 2 files changed, 149 insertions(+)
>> create mode 100644
>> tests/spec/glsl-1.50/execution/vs-gs-arrays-fail.shader_test
>> create mode 100644
>> tests/spec/glsl-1.50/execution/vs-gs-arrays-within-blocks-pass.shader_test
>>
>> diff --git a/tests/spec/glsl-1.50/execution/vs-gs-arrays-fail.shader_test
>> b/tests/spec/glsl-1.50/execution/vs-gs-arrays-fail.shader_test
>> new file mode 100644
>> index 0000000..877b0a6
>> --- /dev/null
>> +++ b/tests/spec/glsl-1.50/execution/vs-gs-arrays-fail.shader_test
>> @@ -0,0 +1,63 @@
>> +# Test that vertex array outputs are not allowed outside of output
>> blocks since
>> +# 2D arrays are not supported.
>>
>
> This comment is a little misleading because vertex array outputs acually
> *are* allowed. What you're actually testing is that the linker rejects
> trying to link a vertex array outputs up to a geometry shader array input.
> I'd recommend saying something like:
>
> "Test that a vertex shader array output (outside an interface block) can't
> be linked to a geometry shader array input."
>
>
>> +#
>> +# From the GLSL 1.50 specification, section 4.3.4 ("Inputs"):
>> +#
>> +# "If the output of a vertex shader is itself an array to be consumed by
>> a
>> +# geometry shader, then it must appear in an output block (see
>> interface blocks
>> +# below) in the vertex shader and in an input block in the geometry
>> shader with
>> +# a block instance name declared as an array. This is required for
>> arrays
>> +# output from a vertex shader because two-dimensional arrays are not
>> +# supported."
>> +
>> +[require]
>> +GL >= 3.2
>> +GLSL >= 1.50
>> +
>> +[vertex shader]
>> +
>> +in vec4 vertex;
>> +
>> +out vec4 pos;
>> +out float a[3];
>> +
>> +void main()
>> +{
>> + gl_Position = vertex;
>> + pos = vertex;
>> + for(int i = 0; i < 3; i++) {
>> + a[i] = i+1;
>> + }
>> +}
>> +
>> +[geometry shader]
>> +
>> +layout(triangles) in;
>> +layout(triangle_strip, max_vertices = 3) out;
>> +
>> +in vec4 pos[];
>> +in float a[3];
>> +
>> +
>> +void main()
>> +{
>> +}
>> +
>> +[fragment shader]
>> +
>> +out vec4 color;
>> +
>> +void main()
>> +{
>> + color = vec4(1.0, 0.0, 0.0, 1.0);
>> +}
>> +
>> +[vertex data]
>> +vertex/float/2
>> +-1.0 -1.0
>> + 1.0 -1.0
>> + 1.0 1.0
>> +-1.0 1.0
>> +
>> +[test]
>> +link error
>> diff --git
>> a/tests/spec/glsl-1.50/execution/vs-gs-arrays-within-blocks-pass.shader_test
>> b/tests/spec/glsl-1.50/execution/vs-gs-arrays-within-blocks-pass.shader_test
>> new file mode 100644
>> index 0000000..52b8b00
>> --- /dev/null
>> +++
>> b/tests/spec/glsl-1.50/execution/vs-gs-arrays-within-blocks-pass.shader_test
>> @@ -0,0 +1,86 @@
>> +# Test that vertex array outputs that are passed to a geometry shader
>> are only
>> +# valid if they are declared within an output block.
>>
>
> I'd drop the word "only" from the test description here, since this
> partuclar test checks that vertex array outputs work when they are in an
> interface block; it doesn't check that they don't work when they aren't.
>
> With those two minor comment changes, this patch is:
>
> Reviewed-by: Paul Berry <stereotype441 at gmail.com>
>
Wait, sorry, I take that back. I have one more comment, which I think
needs to be addressed before we can go forward with the patch.
>
>
>> +#
>> +# From the GLSL 1.50 specification, section 4.3.4 ("Inputs"):
>> +#
>> +# "If the output of a vertex shader is itself an array to be consumed by
>> a
>> +# geometry shader, then it must appear in an output block (see
>> interface blocks
>> +# below) in the vertex shader and in an input block in the geometry
>> shader with
>> +# a block instance name declared as an array. This is required for
>> arrays
>> +# output from a vertex shader because two-dimensional arrays are not
>> +# supported."
>> +
>> +[require]
>> +GL >= 3.2
>> +GLSL >= 1.50
>> +
>> +[vertex shader]
>> +
>> +in vec4 vertex;
>> +
>> +out vec4 pos;
>> +out block {
>> + float a[4];
>> +};
>> +
>> +void main()
>> +{
>> + gl_Position = vertex;
>> + pos = vertex;
>> + for(int i = 0; i < 4; i++) {
>> + a[i] = i+1;
>> + }
>> +}
>> +
>> +[geometry shader]
>> +
>> +layout(triangles) in;
>> +layout(triangle_strip, max_vertices = 3) out;
>> +
>> +in vec4 pos[];
>> +in block {
>> + float a[4];
>> +} b[];
>> +
>> +out float aa[4];
>> +
>> +void main()
>> +{
>> + for(int i = 0; i < 3; i++) {
>> + gl_Position = pos[i];
>> + for(int j = 0; j < 4; j++) {
>> + aa[j] = b[i].a[j];
>>
>
The vertex shader always outputs the same data to each element of the "a"
array, regardless of which vertex is being processed. As a result, when
the geometry shader gets to this line, we really aren't testing that the
array indexing works correctly. For instance, if the compiler accidentally
compiled this as:
aa[j] = b[0].a[j]
The test would still pass.
I'd recommend changing the test so that the vertex shader outputs different
values on each vertex, and so that the geometry shader checks that the
expected values are received. For an example of one way to do this, see
"[PATCH] gs: Test core GS inputs on GLSL 1.50" (
http://lists.freedesktop.org/archives/piglit/2013-September/007340.html),
which I sent to the piglit list on 9/14.
> + }
>> + EmitVertex();
>> + }
>> +}
>> +
>> +[fragment shader]
>> +
>> +in float aa[4];
>> +
>> +out vec4 color;
>> +
>> +void main()
>> +{
>> + bool fail = false;
>> + for(int i = 0; i < 4; i++) {
>> + if(aa[i] != i + 1) fail = true;
>> + }
>> +
>> + if (fail)
>> + color = vec4(1.0, 0.0, 0.0, 1.0);
>> + else
>> + color = vec4(0.0, 1.0, 0.0, 1.0);
>> +}
>> +
>> +[vertex data]
>> +vertex/float/2
>> +-1.0 -1.0
>> + 1.0 -1.0
>> + 1.0 1.0
>> +-1.0 1.0
>> +
>> +[test]
>> +draw arrays GL_TRIANGLE_FAN 0 4
>> +probe all rgba 0.0 1.0 0.0 1.0
>> --
>> 1.8.3.1
>>
>> _______________________________________________
>> Piglit mailing list
>> Piglit at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/piglit
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20130916/d0fba544/attachment.html>
More information about the Piglit
mailing list