[Mesa-dev] Possible bug with r600g shader compiler

[Vadim Girlin]

On 03/31/2013 04:51 PM, Martin Andersson wrote:
> Hi,
>
> I think have found a bug in the r600g shader compiler. I have a AMD 6950
> and I'm running mesa from git.
>
> The bug is exercised by the the vertex shader program in piglit
> ext_transform_feedback/order.c
>
> I have simplified the shader program so the compiled shader is easier to read:
>
> #version 130
> in uint starting_x;
> flat out uint starting_x_copy;
> flat out uint iteration_count;
> flat out uint shift_reg_final;
> uniform uint shift_count;
>
> void main()
> {
>      gl_Position = vec4(0.0);
>      uint x = starting_x;
>      uint count = 0u;
>      uint shift_reg = 1u;
>      starting_x_copy = starting_x;
>      uint k;
>      while (x != 0u) {
>          shift_reg = shift_count;
>          for (k = 0u; k < shift_count; ++k)
>              ++count;
>          x = 0u;
>      }
>      iteration_count = count;
>      shift_reg_final = shift_reg;
> }
>
> It compiles to, http://pastebin.com/cQ8rbKCv.
>
> input:
> shift_count 64
> starting_x 0
>
> actual output:
> iteration_count 1
> shift_reg 1
>
> expected output:
> iteration_count 0
> shift_reg 1
>
> When the shader is run with starting_x set to 0 the iteration_count output is 1.
> That should be impossible since the ++count is inside the while loop guarded
> by x != 0. That the iteration_count is 1 and not 64 is also strange, it seems
> to somehow have gotten past the while guard but only executed one iteration in
> the for loop before exiting again. Another thing to note is that shift_reg
> is not set to 64.
>
> If I write 64 instead of shift_count in the for loop (k < 64u) (effectivily
> optimizing it to 64 add statements instead of a loop) or switch the while
> to an if, the program behaves as expected. That leads me to belive that
> the issue is with the two nested loops.
>
> The docs mentions something about nested flowcontrol for PRED_SETE_64.
>
> "The instruction can also establish a predicate result (execute or skip) for
> subsequent predicated instruction execution. This additional control allows a
> compiler to support one-instruction issue for if-elseif operations, or an
> integer result for nested flow-control, by using single-precision operations
> to manipulate a predicate counter."
>
> But the while and for loops are compiled to PRED_SETNE_INT which does not have
> that comment. Anyway, I just wanted to include that comment in case it was
> relevant.

Predication is not used with the default compiler backend in r600g 
(currently it may be used with the llvm backend only), so it's not 
relevant. Anyway, this comment applies to all PRED_xxx instructions. 
Omitted comment in the docs doesn't mean anything, some things in the 
docs may be even incorrect.

>
> Anyone knows whats wrong or have any ideas for how I could debug it further?

You might want to modify the test to get rid of the transform feedback, 
just to make sure that it's not a transform feedback issue.

Vadim

>
> //Martin
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>