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

[Marek Olšák]

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 <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/**
>>>> **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 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>
>>>> >
>>>>
>>>>
>>>>
>>> ______________________________**_________________
>>> 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>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130410/0ef18964/attachment.html>