[Mesa-dev] [PATCH] r600g: set address of pop instructions to next instruction

Jerome Glisse j.glisse at gmail.com
Fri Dec 3 08:39:03 PST 2010


On Fri, Dec 3, 2010 at 11:11 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Fri, Dec 3, 2010 at 10:30 AM, Jerome Glisse <j.glisse at gmail.com> wrote:
>> On Fri, Dec 3, 2010 at 7:03 AM, Fabian Bieler <der.fabe at gmx.net> wrote:
>>> Hello!
>>>
>>> In R700-family_instruction_set_architecture.pdf
>>> pages 3-18 and 9-34 read that pop instructions never jump.
>>> The table on page 3-16 however reads that it does jump if the condition test
>>> fails for all pixels.
>>>
>>> On RV710 the attached piglit test indicates that the pop instruction does
>>> indeed jump sometimes.
>>>
>>> In the attached image pop instructions are executed in the lower right half
>>> including the diagonal. If the pop instruction jumps the pixel should be
>>> black. I can think of no grouping of four pixels at a time to make sense of
>>> that pattern. So it would seem pop doesn't always jump even if all pixels
>>> fail the condition test.
>>>
>>> Anyway the patch sets the address of pop instructions to the next instruction
>>> which fixes the test.
>>>
>>> Fabian
>>
>> So my understanding is that we wrongly translate loop_break. Loop
>> break shouldn't be followed by a pop, as loop break just disable the
>> pixel in current loop and it's a loop_end that we either keep looping
>> or quit loop and pop. It seems removing call to pops in
>> tgsi_loop_brk_cont is not enough, we might be setting the wrong addr
>> in loop_break.
>>
>
> I talked to Richard and CF_POP is always executed in non whole quad
> mode.  It shouldn't jump, but it's good practice to always set the
> jump address to the next instruction.  r600c always does this.
>
> Alex

Ok pushed Fabian change, thought it still remain unexplain why it's
not working, i looked at output code and it looks fine LOOP_BREAK
properly point to LOOP_END.

Cheers,
Jerome


More information about the mesa-dev mailing list