[Mesa-dev] [PATCH 1/2] i965/fs: Don't let the EOT send message interfere with the MRF hack

[Neil Roberts]

Jason Ekstrand <jason at jlekstrand.net> writes:

> The only place when the fact that the MRFs are virtual matters is in
> register allocation.  Implied MRF writes are taken into account in
> setup_mrf_hack_interference.  We figure out what MRFs are used and
> then mark them as conflicting with *all* of the VGRFs.  We also force
> them to be placed in the correct physical register using
> ra_set_node_reg.  The register allocator is then smart enough to not
> place any other VGRF values into one of those registers.  The problem
> is that we were also forcing the message for the final FB write and we
> were forcing it to overlap.

Ok, that makes sense. Thanks for the explanation.

>> I was thinking it's a bit risky to just use a register that is lower
>> than the lowest used MRF register because it could be possible for a
>> message to use a really low register number and then this would end up
>> using a negative register number. However in practice on Gen7+ it looks
>> like there's hardly anything left that is using the fake MRF and we're
>> unlikely to add more so it probably doesn't really matter.
>
> The maximum length of a message is 16 and we have at most 16 virtual
> MRFs so the message will start no earlier than g96.  I think it's fine
> as long as it's in the upper half or something like that.

Page 1039 of the Broadwell PRM says:

“The send with EOT should use register space R112-R127 for <src>. This
 is to enable loading of a new thread into the same slot while the
 message with EOT for current thread is pending dispatch”

So 96 wouldn't work. I guess that means if anything is using a base_mrf
of 7 or below then it could potentially break. At a glance I can't find
anything that would do that on Gen7+, but maybe it's a bit risky.

Regards,
- Neil