[Mesa-dev] [PATCH] r600g: set address of pop instructions to next instruction
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:
>> 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.
> 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.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev