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

Eric Anholt eric at anholt.net
Wed Feb 13 21:11:40 PST 2013


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130213/8f691d54/attachment.pgp>


More information about the mesa-dev mailing list