[Mesa-dev] [PATCH] r600g: Fix UMAD on Cayman

Wed Apr 10 15:08:02 PDT 2013

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 <vadimgirlin at 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 <vadimgirlin at 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 <vadimgirlin at 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 <maraeo at 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 at 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 at 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>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130411/63c7701e/attachment.html>