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
Marek On Wed, Apr 10, 2013 at 11:42 PM, Vadim Girlin <vadimgir...@gmail.com>wrote: > On 04/10/2013 01:53 PM, Marek Olšák wrote: > >> glsl-fs-loop-nested passes here. >> >> nstack is 3 and adding 4 to it doesn't help. >> > > 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 > > > >> 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/**<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-**<http://freedesktop.org/archives/mesa-**> >>>>>> dev/2013-March/036941.html<htt**p://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> >>>>>> <h**ttp://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> >>>>>> <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<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
