On 2015-10-30 09:28:10, Matt Turner wrote: > On Fri, Oct 30, 2015 at 4:11 AM, Iago Toral Quiroga <ito...@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? -Jordan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
