<div dir="ltr"><div>I think the transform feedback code is correct, because all the other TFB tests pass. If there is an issue, it must be in the shader.<br><br></div>Marek<br><div class="gmail_extra"><br><br><div class="gmail_quote">


On Tue, Apr 9, 2013 at 8:58 AM, Martin Andersson <span dir="ltr"><<a href="mailto:g02maran@gmail.com" target="_blank">g02maran@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
> Pushed, thanks. The transform feedback test still doesn't pass, but at least<br>
> the hardlocks are gone.<br>
<br>
</div>Thanks, I have looked into the other issue as well<br>
<a href="http://lists.freedesktop.org/archives/mesa-dev/2013-March/036941.html" target="_blank">http://lists.freedesktop.org/archives/mesa-dev/2013-March/036941.html</a><br>
<br>
The problem arises when there are nested loops. If I rework the code<br>
so there are<br>
no nested loops the issue disappears. At least one pixel also needs to enter the<br>
outer loop. The pixels that should enter the outer loop behaves<br>
correctly. It is those<br>
pixels that should not enter the outer loop that misbehaves. It does<br>
not matter if they<br>
also fails the test for the inner loop, they will still execute the<br>
instruction inside. That<br>
leads to the strange results for that test.<br>
<br>
The strangeness is easier to see if the NUM_POINTS in the<br>
ext_transform_feedback/<br>
order.c are run with smaller values,like 3, 6 and 9. Disable the code<br>
that fail the test<br>
and print starting_x, shift_reg_final and iteration_count.<br>
<br>
Marek, since you implemented transform feedback for r600, do you think the issue<br>
is with the tranform feedback code or the shader compiler or some other thing?<br>
<span><font color="#888888"><br>
//Martin<br>
</font></span></blockquote></div><br></div></div>