[Mesa-dev] [PATCH 00/10] i965: always mark used surfaces in the visitors
jordan.l.justen at intel.com
Fri Oct 30 14:56:03 PDT 2015
On 2015-10-30 09:28:10, Matt Turner wrote:
> On Fri, Oct 30, 2015 at 4:11 AM, Iago Toral Quiroga <itoral at igalia.com> wrote:
> > Right now some opcodes that only use constant surface indexing mark them as
> > used in the generator while others do it in the visitor. When the opcode can
> > handle both direct and indirect surface indexing then some opcodes handle
> > only the constant part in the generator and leave the indirect case to the
> > caller. It is all very inconsistent and leads to confusion, since one has to
> > go and look into the generator code in each case to check if it marks surfaces
> > as used or not, and in which cases.
> > when I was working on SSBOs I was tempted to try and fix this but then I
> > forgot. Jordan bumped into this recently too when comparing visitor
> > code paths for similar opcodes (ubos and ssbos) that need to handle this
> > differently because they use different generator opcodes.
> > Since the generator opcodes never handle marking of indirect surfaces, just
> > leave surface marking to the caller completely, since callers always have
> > all the information needed for this. It also makes things more consistent
> > and clear for everyone: marking surfaces as used is always on the side
> > of the visitor, never the generator.
> What happens if we dead code eliminate the last texture() on a given
> surface? Before in the constant indexed case, we wouldn't mark the
> surface as used, but since this series moves that to the NIR ->
> backend IR translation, presumably it'll still be marked used?
> Is that important, and if so is there anything we can do to "unmark"
> the unused surface?
Seems like a good point, but I can't comment on how important that is.
This could apply to indirect accesses as well, right? But, I guess we
can't deal with that being optimized out today.
What if we had a range of possible surfaces referenced in the
backend_instruction struct? Could we then just look over them once
after optimizing to find out the max surface used?
More information about the mesa-dev