On Fri, Dec 3, 2010 at 11:11 AM, Alex Deucher <alexdeuc...@gmail.com> wrote: > 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
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
