On 13 February 2013 21:11, Eric Anholt <e...@anholt.net> wrote: > Kenneth Graunke <kenn...@whitecape.org> writes: > > > On 02/13/2013 06:31 PM, Eric Anholt wrote: > >> Kenneth Graunke <kenn...@whitecape.org> writes: > >> > >>> Meta-instructions that implicitly write then read/consume a MRF value > >>> don't pose write-after-write conflicts with each other, since they're > >>> actually: > >>> > >>> - Write value 1, then consume it. > >>> - Write value 2, then consume it. > >> > >> OK, here's the case I'm thinking of: > >> > >> 1: MOV m2, temp1 > >> 2: send m2 no_implied_write > >> 3: send m2 implied_write_m2 > >> 4: send m2 implied_write_m2 > >> 5: MOV m2, temp2 > >> 6: send m2 no_implied_write > >> > >> Before this series we had deps: > >> 2 -> 1 (RAW) > >> 3 -> 2 (WAW) > >> 4 -> 3 (WAW) > >> 5 -> 4 (WAW) > >> 6 -> 5 (RAW) > >> > >> I'm concerned that now you only have deps: > >> 2 -> 1 (RAW) > >> 3 -> 2 (WAW) > >> 5 -> 4 (WAW) > >> 5 -> 2 (RAW) > >> 6 -> 5 (RAW) > >> > >> and that now a possible ordering would be: > >> > >> 1: MOV m2, value > >> 2: send m2 no_implied_write > >> 4: send m2 implied_write_m2 > >> 5: MOV m2, value > >> 3: send m2 implied_write_m2 > >> 6: send m2 no_implied_write > >> > >> and "6: send" will be broken. > >> > >> I could definitely have missed something -- this stuff is super twisty. > > > > I double checked your work and got an extra 3 -> 1 (WAW) dependency, but > > that doesn't matter. The reordering you mentioned is indeed possible. > > Thanks. > > > > Consider patches 1 & 2 NAK'd...I'm working on a new series... > > In releated news, we got a report today that ubo performance sucks (not > surprising, right?), and the testcase shows repeated loads from the same > offset. That makes me think that we want to have a single IR > instruction for "load from this UBO surface at this offset" which can > get CSEd, and then before the post-regalloc scheduling we would lower it > to the sequence of 3 instructions we use now. That could deal with > avoiding these dependencies for the case we need to deal with here, > right? Of course, it would need to use a reserved range of MRFs like > spill/unspill do (though it could be the same range), so that it doesn't > interfere with anything when scheduled between some other instruction > sequence's MRF setup and its SEND. >
That sounds like a great idea to me. > > > _______________________________________________ > 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
