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

Alex Deucher alexdeucher at gmail.com
Fri Dec 3 08:11:46 PST 2010


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

> Cheers,
> Jerome
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


More information about the mesa-dev mailing list