[Intel-gfx] [PATCH 13/15] drm/i915: Allow execbuffer to use the first object as the batch

[Kenneth Graunke]

On Friday, July 7, 2017 3:17:22 AM PDT Daniel Vetter wrote:
> On Fri, Mar 17, 2017 at 12:15 PM, Joonas Lahtinen
> <joonas.lahtinen at linux.intel.com> wrote:
> > On to, 2017-03-16 at 13:20 +0000, Chris Wilson wrote:
> >> Currently, the last object in the execlist is the always the batch.
> >> However, when building the batch buffer we often know the batch object
> >> first and if we can use the first slot in the execlist we can emit
> >> relocation instructions relative to it immediately and avoid a separate
> >> pass to adjust the relocations to point to the last execlist slot.
> >>
> >> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >
> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> This patch was reviewed/pushed full month before the mesa patch was
> fully reviewed and ready for merging. That's not how uapi is done.
> 
> I've fixed this up now by at least reviewing the mesa patch, but for
> next time around: If you review uapi, and you don't make sure the
> userspace side is in good shape too, then you've not reviewed the
> patch properly.
> 
> Same goes for reviewing and not making sure there's tests, but that's
> another rant.
> 
> Ken, pls make sure we don't end up with another case like resource
> streamer (or tell me I should revert this).
> -Daniel

Sorry, that's partly my bad - I had mentioned to Chris that I wanted this
feature, and planned to use it, but then got distracted with other work and
didn't get around to actually shipping a patch to do so.  Both Chris and I
wrote patches, and IIRC I was benchmarking things when I got distracted.

Basically, I915_EXEC_HANDLE_LUT appeared to be a performance loss in the
CPU bound benchmarks I looked at, because we had to walk over one of the
lists and patch up references to the batch (-1 => actual index).

BATCH_FIRST eliminates that overhead, making HANDLE_LUT actually useful
(although only a small amount).

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170707/6bc98dda/attachment.sig>