[Piglit] [PATCH] Test dependency hints on exp2 instructions.

[Mike Stroyan]

Reviewed-by: Mike Stroyan <mike at lunarg.com>

That does show the math dependency problem.
The same problem can also be demonstrated with other math opcodes than exp2.



On Mon, Mar 31, 2014 at 5:21 PM, Matt Turner <mattst88 at gmail.com> wrote:

> ---
>  tests/shaders/dependency-hints/exp2.shader_test | 72
> +++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>  create mode 100644 tests/shaders/dependency-hints/exp2.shader_test
>
> diff --git a/tests/shaders/dependency-hints/exp2.shader_test
> b/tests/shaders/dependency-hints/exp2.shader_test
> new file mode 100644
> index 0000000..c7584e6
> --- /dev/null
> +++ b/tests/shaders/dependency-hints/exp2.shader_test
> @@ -0,0 +1,72 @@
> +[require]
> +GLSL >= 1.10
> +
> +[vertex shader]
> +/* On Sandybridge and newer chips in the i965 family, writes into separate
> + * channels of the same register stall. The compiler marks independent
> writes
> + * with NoDDClr and/or NoDDChk to allow the instructions to issue without
> + * stalling.
> + *
> + * Empirically, marking "math" instructions with these dependency control
> + * hints leads to broken dependency tracking. The following shader,
> compiled
> + * with the i965/vec4 backend unaware of this fact generates the following
> + * assembly:
> + *
> + * math exp(8)     g3<1>.xF        g1<0,4,1>.xF    null            {
> align16 WE_normal NoDDClr 1Q };
> + * add(8)          g7<1>F          g1<0,4,1>.yF    1e-08F          {
> align16 WE_normal 1Q };
> + * math exp(8)     g3<1>.yF        g7<4,4,1>F      null            {
> align16 WE_normal NoDDClr,NoDDChk 1Q };
> + * math exp(8)     g3<1>.zF        g1<0,4,1>.zF    null            {
> align16 WE_normal NoDDChk 1Q };
> + * mul.sat(8)      g116<1>.xyzF    g3<4,4,1>.xyzzF 0.5F            {
> align16 WE_normal NoDDClr 1Q };
> + * mov.sat(8)      g116<1>.wF      1F                              {
> align16 WE_normal NoDDChk 1Q };
> + * mov(8)          g114<1>D        0D                              {
> align16 WE_normal 1Q };
> + * mov(8)          g115<1>F        g2<4,4,1>F                      {
> align16 WE_normal 1Q };
> + * mov(8)          g113<1>UD       g0<4,4,1>UD                     {
> align16 WE_all 1Q };
> + * or(1)           g113.5<1>UD     g0.5<0,1,0>UD   0x0000ff00UD    {
> align1 WE_all };
> + * send(8)         null            g113<4,4,1>F
> + *                 urb 0 urb_write used complete mlen 5 rlen 0     {
> align16 WE_normal 1Q EOT };
> + *
> + * The shader calculates the color exp2(vec3(0.1, 0.2 + 0.00000001, 0.3))
> * 0.5
> + * and expects to read back (0.535886, 0.5743491, 0.6155722).
> + *
> + * On affected platforms, the .x and .y components are correctly
> calculated,
> + * but .z is left to be 0.0.
> + */
> +
> +uniform vec3 exp;
> +
> +void main(){
> +   gl_Position = gl_Vertex;
> +
> +   /* Calling exp2() on a single component swizzle and then picking a
> single
> +    * channel from its result works around the vec4 backend's inability to
> +    * properly register coalesce.
> +    */
> +   gl_FrontColor.x = exp2(exp.xxxx).x;
> +
> +   /* Adding 0.00000001 is essentially a no-op, but it prevents the GLSL
> +    * compiler's opt_vectorize pass from combining the three exp2() calls
> +    * into a single one.
> +    */
> +   gl_FrontColor.y = exp2(exp.yyyy + 0.00000001).y;
> +
> +   gl_FrontColor.z = exp2(exp.zzzz).z;
> +
> +   /* Scale the result back into the 0.0 to 1.0 range */
> +   gl_FrontColor.xyz *= 0.5;
> +
> +   /* Moving this assignment before the previous statement causes the test
> +    * to sporadically fail, returning 1.0 (unrelated to value stored in
> .w)
> +    * in all channels.
> +    */
> +   gl_FrontColor.w = 1.0;
> +}
> +
> +[fragment shader]
> +void main() {
> +   gl_FragColor = gl_Color;
> +}
> +
> +[test]
> +uniform vec3 exp 0.1 0.2 0.3
> +draw rect -1 -1 2 2
> +probe rgb 1 1 0.535886 0.5743491 0.6155722
> --
> 1.8.3.2
>
> _______________________________________________
> Piglit mailing list
> Piglit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/piglit
>



-- 

 Mike Stroyan - Software Architect
 LunarG, Inc.  - The Graphics Experts
 Cell:  (970) 219-7905
 Email: Mike at LunarG.com
 Website: http://www.lunarg.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140408/ef6015e4/attachment-0001.html>