[Mesa-dev] [PATCH 2/3] i965: Don't record a WAW dependency between implicit MRF operations.

[Paul Berry]

On 13 February 2013 21:11, Eric Anholt <eric at anholt.net> wrote:

> Kenneth Graunke <kenneth at whitecape.org> writes:
>
> > On 02/13/2013 06:31 PM, Eric Anholt wrote:
> >> Kenneth Graunke <kenneth at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130214/adbcfc86/attachment.html>