[Mesa-dev] [RFC 0/3] i965: Enable up to 24 MRF registers in gen6

[Iago Toral]

On Wed, 2015-09-16 at 12:32 -0700, Kenneth Graunke wrote:
> On Wednesday, September 16, 2015 11:17:53 AM Iago Toral Quiroga wrote:
> > It seems that we have some bugs where we fail to compile shaders in gen6
> > because we do not having enough MRF registers available (see bugs 86469 and
> > 90631 for example). That triggered some discussion about the fact that SNB
> > might actually have 24 MRF registers available, but since the docs where not
> > very clear about this, it was suggested that it would be nice to try and
> > experiment if that was the case.
> > 
> > These series of patches implement such test, basically they turn our fixed
> > BRW_MAX_MRF into a macro that accepts the hardware generation and then changes
> > the spilling code in brw_fs_reg_allocate.cpp to use MRF registers 21-23 for
> > gen6 (something similar can be done for the vec4 code, I just did not do it
> > yet).
> > 
> > The good news is that this seems to work fine, at least I can do a full piglit
> > run without issues in SNB.
> 
> Sweet!
> 
> > In fact, this seems to help a lot of tests when I
> > force spilling of everything in the FS backend (INTEL_DEBUG=spill_fs):
> > 
> > Using MRF registers 13-15 for spilling:
> > crash: 5, fail 267, pass: 15853, skip: 11679, warn: 3
> > 
> > Using MRF registers 21-23 for spilling:
> > crash: 5, fail 140, pass: 15980, skip: 11679, warn: 3
> > 
> > As you can see, we drop the fail ratio to almost 50%...
> 
> That seems odd - I wouldn't think using m13-15 vs. m21-23 would actually
> make a difference.  Perhaps it's papering over a bug where we're failing
> to notice that MRFs are in use?  If so, we should probably fix that (in
> addition to making this change).

(...)

I've looking into this. The problem was happening because our UBO loads
(via sampler messages) use MRF14 in gen6, so as soon as we had one of
these, get_used_mrfs in brw_fs_reg_allocate.cpp would detect that MRF14
is used and fail building any shader that needs spilling. This is quite
extreme, since just because MRF14 is used by something else tt does not
mean that there is an actual conflict, in fact, the test I was playing
with (fs-bools.shader_test) was a case of a false positive.

I suppose that a better way to do this would be to check if any write to
MRF14 prior to the current instruction needing spilling has been already
consumed by a matching SEND instruction also happening before the
instruction we need to spill for. However, now that we moved spilling to
a different MRF range this can't happen any more, so I wonder if we want
to implement this.

One more thing that this brought to my attention is that we probably
want to move UBO loads in gen6 to MRFs > 15 (and < 21, where we do our
spills). This is because our URB writes in gen6 can now happen in MRF
1..15. The likelihood of a conflict, I guess, is very small anyway,
specially because URB writes are bound to be the last thing to happen,
but maybe there is a rare case where this could bite us so I think we
are probably better off moving our UBO loads out of the conflict zone.

BTW, apparently, this does not happen in gen7+ because that uses GRF
registers for SEND instructions instead of MRFs and this code checks for
MRF destinations.

Iago