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

<br>
<br>_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
<br></blockquote></div><br></div></div>