glsl-fs-loop-nested passes here. nstack is 3 and adding 4 to it doesn't help.
Marek On Wed, Apr 10, 2013 at 8:46 AM, Vadim Girlin <vadimgir...@gmail.com> wrote: > On 04/10/2013 03:58 AM, Marek Olšák wrote: > >> Hi Vadim, >> >> your patch does not fix the test. >> > > 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 > > > >> Marek >> >> >> On Tue, Apr 9, 2013 at 11:30 PM, Vadim Girlin <vadimgir...@gmail.com> >> wrote: >> >> On 04/09/2013 10:58 AM, Martin Andersson wrote: >>> >>> On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák <mar...@gmail.com> wrote: >>>> >>>> Pushed, thanks. The transform feedback test still doesn't pass, but at >>>>> least >>>>> the hardlocks are gone. >>>>> >>>>> >>>> Thanks, I have looked into the other issue as well >>>> http://lists.freedesktop.org/****archives/mesa-dev/2013-March/** >>>> **036941.html<http://lists.freedesktop.org/**archives/mesa-dev/2013-March/**036941.html> >>>> <http://lists.**freedesktop.org/archives/mesa-** >>>> dev/2013-March/036941.html<http://lists.freedesktop.org/archives/mesa-dev/2013-March/036941.html> >>>> > >>>> >>>> >>>> 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. >>>> >>>> >>> Please test the attached patch. >>> >>> Vadim >>> >>> >>> The strangeness is easier to see if the NUM_POINTS in the >>>> 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 >>>> ______________________________****_________________ >>>> mesa-dev mailing list >>>> mesa-dev@lists.freedesktop.org >>>> http://lists.freedesktop.org/****mailman/listinfo/mesa-dev<http://lists.freedesktop.org/**mailman/listinfo/mesa-dev> >>>> <htt**p://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev> >>>> > >>>> >>>> >>>> >>> ______________________________**_________________ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev> >>> >>> >>> >> >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
