[Mesa-dev] [PATCH 00/10] i965: always mark used surfaces in the visitors

Matt Turner mattst88 at gmail.com
Sat Oct 31 12:00:25 PDT 2015

On Sat, Oct 31, 2015 at 10:13 AM, Francisco Jerez <currojerez at riseup.net> wrote:
> Jordan Justen <jordan.l.justen at intel.com> writes:
>> 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 there any example (e.g. from shader-db) of texture call that the
> back-end would be able to DCE but not NIR?

Yeah, that does seem pretty unlikely. Okay then! :)

More information about the mesa-dev mailing list