On pe, 2017-07-21 at 15:50 +0100, Chris Wilson wrote:
> I was being overly paranoid in not updating the execobject.offset after
> performing the fallback copy where we set reloc.presumed_offset to -1.
> The thinking was to ensure that a subsequent NORELOC execbuf would be
> forced to process the invalid relocations. However this is overkill so
> long as we *only* update the execobject.offset following a successful
> update of the relocation value witin the batch. If we have to repeat the
> execbuf due to a later interruption, then we may skip the relocations on
> the second pass (honouring NORELOC) since the execobject.offset match
> the actual offsets (even though reloc.presumed_offset is garbage).
>
> Subsequent calls to execbuf with NORELOC should themselves ensure that
> the reloc.presumed_offset have been corrected in case of future
> migration.
>
> Reporting back the actual execobject.offset, even when
> reloc.presumed_offset is garbage, ensures that reuse of those objects
> use the latest information to avoid relocations.
>
> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
