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

[Francisco Jerez]

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?  I have the feeling that even
the NIR->i965 IR translation might be too late to find out which subset
of BTIs can potentially be referenced by the shader, because some of the
useful UBO and SSBO array bounds information is already gone (so we
pessimistically assume that *all* U/SSBOs may be used).

Anyway the information provided to brw_mark_surface_used() is currently
only used to determine the maximum BTE to upload, so e.g. marking any
UBO as used causes all texture BTEs to be uploaded too as a side effect.
Anyway a BTE is just an additional 32-bit pointer at state upload time
so I guess not a huge deal...

>> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151031/fbabf006/attachment-0001.sig>