[Mesa-dev] [PATCH 10/32] i965/fs: Remove logic to keep track of MRF metadata in lower_load_payload().

Jason Ekstrand jason at jlekstrand.net
Thu Feb 19 13:53:16 PST 2015


On Thu, Feb 19, 2015 at 1:25 PM, Francisco Jerez <currojerez at riseup.net>
wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > On Thu, Feb 19, 2015 at 12:13 PM, Francisco Jerez <currojerez at riseup.net
> >
> > wrote:
> >
> >> Jason Ekstrand <jason at jlekstrand.net> writes:
> >>
> >> > On Fri, Feb 6, 2015 at 4:01 PM, Francisco Jerez <
> currojerez at riseup.net>
> >> > wrote:
> >> >
> >> >> Hey Matt,
> >> >>
> >> >> Matt Turner <mattst88 at gmail.com> writes:
> >> >>
> >> >> > On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez <
> >> currojerez at riseup.net>
> >> >> wrote:
> >> >> >> MRFs cannot be read from anyway so they cannot possibly be a valid
> >> >> >> source of LOAD_PAYLOAD.
> >> >> >> ---
> >> >> >
> >> >> > The function only seems to test inst->dst.file == MRF. I don't see
> any
> >> >> > code for handling MRF sources. What am I missing?
> >> >>
> >> >> That test is for "handling" MRF sources -- More precisely, it's
> >> >> collecting the writemask and half flags for MRF writes, which can
> only
> >> >> possibly be useful if we're going to use them later on to read
> something
> >> >> out of an MRF into a payload, which we shouldn't be doing in the
> first
> >> >> place.
> >> >>
> >> >> Aside from simplifying the function somewhat, that allows us to drop
> the
> >> >> 16 register gap reserved for MRFs at register offset zero, what will
> >> >> allow us to drop the vgrf_to_reg[] offset calculation completely
> (also
> >> >> in split_virtual_grfs()) in a future patch (not sent for review yet).
> >> >>
> >> >
> >> > No, we do read from MRF's sort-of...  Send messages have an implicit
> >> "read"
> >> > from an MRF.
> >>
> >> Heh, and that's pretty much the only way you "read" from it.
> >>
> >> > This was written precicely so that we could use LOAD_PAYLOAD
> >> > to build MRF payloads.  We do on pre-GEN6.
> >> >
> >> I'm aware, but you don't need any of this meta-data to LOAD_PAYLOAD
> >> *into* an MRF, and LOAD_PAYLOAD with an MRF as source should be illegal
> >> anyway.
> >>
> >
> > And no one is using it that way.  All of the metadata checks you are
> > deleting are checks on the *destination*.
> >
>
> Didn't you write this code yourself?  The only use for the collected
> metadata is initializing the instruction flags of the MOVs subsequent
> LOAD_PAYLOAD instructions are lowered to, based on the metadata already
> collected for its source registers, which can never be MRFs, so the
> metadata you collect from MRF writes is never actually used.
>

Right... I misred something initially.  Yes, we should never be tracking
MRF's as a source of a LOAD_PAYLOAD.  I'll give it a better look a bit
later, but it looks better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150219/28985829/attachment.html>


More information about the mesa-dev mailing list