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

Jason Ekstrand jason at jlekstrand.net
Tue Jun 9 11:46:58 PDT 2015

On Tue, Jun 9, 2015 at 11:11 AM, Neil Roberts <neil at linux.intel.com> wrote:
> 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”

Experimental evidence suggests that this is a bit conservative.  Back
when I first started using GRFs for sends, I did some experiments and
anywhere towards the top seems to work ok.

> 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.

The other thing to remember is that the MRF hack is *only* used for
spilling on GEN7+ as of when we started using GRFs for fb writes.
Therefore, the most MRFs we can possibly have is 3.  It's still
possible to go outside 112-127, but it's pretty hard at that point.
Basically, you would have to have a 15 or 16 register message with
spilling.  I don't know if that's possible today.

More information about the mesa-dev mailing list