<div dir="ltr"><div>Here's the output: creating vs ... shader compilation status: OK creating fs ... shader compilation status: OK thread #0 (0;0) : ref = 16608 thread #1 (1;0) : ref = 27873 thread #2 (0;1) : ref = 16608 thread #3 (1;1) : ref = 27877 results: thread 0 (0, 0): expected = 16608, observed = 27876, FAIL thread 1 (1, 0): expected = 27873, observed = 27873, OK thread 2 (0, 1): expected = 16608, observed = 27876, FAIL thread 3 (1, 1): expected = 27877, observed = 27877, OK </div>Marek <div class="gmail_extra"> <div class="gmail_quote">On Wed, Apr 10, 2013 at 11:42 PM, Vadim Girlin <<a href="mailto:vadimgirlin@gmail.com" target="_blank">vadimgirlin@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 04/10/2013 01:53 PM, Marek Olšák wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> glsl-fs-loop-nested passes here. nstack is 3 and adding 4 to it doesn't help. </blockquote> </div> Ok, thanks. Also I wrote a simple test app that should reproduce the issue if it's really related to diverging control flow with nested loops and might more information about what's going wrong. The source is in the attachment and needs to be compiled with -lGL -lglut -lGLEW. The app renders four points and computes some value for each point in the loops similar to the transform feedback order test, but it doesn't use tfb. It should render four green or red squares depending on correctness of the result. Here is the correct output produced for me on evergreen: thread 0 (0, 0): expected = 16608, observed = 16608, OK thread 1 (1, 0): expected = 27873, observed = 27873, OK thread 2 (0, 1): expected = 16608, observed = 16608, OK thread 3 (1, 1): expected = 27877, observed = 27877, OK Please post the output if it fails on cayman. Vadim <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> Marek On Wed, Apr 10, 2013 at 8:46 AM, Vadim Girlin <<a href="mailto:vadimgirlin@gmail.com" target="_blank">vadimgirlin@gmail.com</a>> wrote: </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> On 04/10/2013 03:58 AM, Marek Olšák wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Vadim, your patch does not fix the test. </blockquote> Hmm, I'm out of ideas then. Thanks for testing. I've checked the shader dump few times but I don't see anything obviously wrong there, and the same code (except the minor ALU grouping changes due to the VLIW4/VLIW5 difference) works fine for me on evergreen. According to the Martin's observations it looks like if the threads that shouldn't execute the loop body were incorrectly left in the active state. LOOP_BREAK should put them into the inactive-break state, but something goes wrong. Do the other piglit tests with nested loops (e.g. glsl-fs-loop-nested) work on cayman? Though possibly there are no other tests with the diverging loops as in this case. I'll try to write a simpler test with the diverging loops to see if the issue is really caused by the incorrect control flow handling, and to figure out the exact instruction that results in the incorrect active state. Also probably it worth checking if the stack size is correct for that shader (latest mesa should print nstack value in the shader disassemble header, I think it should be 3 for that shader) and maybe try adding some constant, e.g. 4 to the bc->nstack in the r600_bytecode_build just to be sure that we reserve enough of stack space, though I don't think stack size is the cause of this issue. Vadim </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> Marek On Tue, Apr 9, 2013 at 11:30 PM, Vadim Girlin <<a href="mailto:vadimgirlin@gmail.com" target="_blank">vadimgirlin@gmail.com</a>> wrote: On 04/09/2013 10:58 AM, Martin Andersson wrote: </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><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: </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> Pushed, thanks. The transform feedback test still doesn't pass, but at <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> least the hardlocks are gone. </blockquote> Thanks, I have looked into the other issue as well </div></div><a href="http://lists.freedesktop.org/****archives/mesa-dev/2013-March/**" target="_blank">http://lists.freedesktop.org/****archives/mesa-dev/2013-March/**</a> **036941.html<<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>> <<a href="http://lists." target="_blank">http://lists.</a>**<a href="http://freedesktop.org/archives/mesa-**" target="_blank">freedesktop.org/archives/mesa-**</a> dev/2013-March/036941.html<<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>><div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote> The problem arises when there are nested loops. If I rework the code so there are no nested loops the issue disappears. At least one pixel also needs to enter the outer loop. The pixels that should enter the outer loop behaves correctly. It is those pixels that should not enter the outer loop that misbehaves. It does not matter if they also fails the test for the inner loop, they will still execute the instruction inside. That leads to the strange results for that test. </div></blockquote><div> Please test the attached patch. Vadim The strangeness is easier to see if the NUM_POINTS in the </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> ext_transform_feedback/ order.c are run with smaller values,like 3, 6 and 9. Disable the code that fail the test and print starting_x, shift_reg_final and iteration_count. Marek, since you implemented transform feedback for r600, do you think the issue is with the tranform feedback code or the shader compiler or some other thing? //Martin </div> ______________________________****_________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/****mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/****mailman/listinfo/mesa-dev</a><<a href="http://lists.freedesktop.org/**mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/**mailman/listinfo/mesa-dev</a>> <htt**p://<a href="http://lists.freedesktop.org/**mailman/listinfo/mesa-dev" target="_blank">lists.freedesktop.org/**mailman/listinfo/mesa-dev</a><<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote> </blockquote><div> ______________________________**_________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/**mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/**mailman/listinfo/mesa-dev</a><<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>> </div></blockquote> </blockquote> </blockquote> </blockquote> </blockquote></div> </div></div>