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

[Vadim Girlin]

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>
>>>
>>> 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>
>>>
>>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>