On Fri, Dec 3, 2010 at 10:30 AM, Jerome Glisse <j.gli...@gmail.com> wrote: > On Fri, Dec 3, 2010 at 7:03 AM, Fabian Bieler <der.f...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
