On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote: > In preparation to support many distinct timelines, we need to expand the > activity tracking on the GEM object to handle more than just a request > per engine. We already use the struct reservation_object on the dma-buf > to handle many fence contexts, so integrating that into the GEM object > itself is the preferred solution. (For example, we can now share the same > reservation_object between every consumer/producer using this buffer and > skip the manual import/export via dma-buf.) > > v2: Reimplement busy-ioctl (by walking the reservation object), postpone > the ABI change for another day. Similarly use the reservation object to > find the last_write request (if active and from i915) for choosing > display CS flips. > > Caveats: > > * busy-ioctl: busy-ioctl only reports on the native fences, it will not > warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is > being rendered to by external fences. It also will not report the same > busy state as wait-ioctl (or polling on the dma-buf) in the same > circumstances. On the plus side, it does retain reporting of which > *i915* engines are engaged with this object. > > * non-blocking atomic modesets take a step backwards as the wait for > render completion blocks the ioctl. This is fixed in a subsequent > patch to use a fence instead for awaiting on the rendering, see > "drm/i915: Restore nonblocking awaits for modesetting" > > * dynamic array manipulation for shared-fences in reservation is slower > than the previous lockless static assignment (e.g. gem_exec_lut_handle > runtime on ivb goes from 42s to 66s), mainly due to atomic operations. > > * loss of object-level retirement callbacks, emulated by VMA retirement > tracking. > > * minor loss of object-level last activity information from debugfs, > could be replaced with per-vma information if desired > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Code duplication is gone, busy-ioctl back, so keeping my; 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
