• C
    drm/i915: Pipelined fencing [infrastructure] · d9e86c0e
    Chris Wilson 提交于
    With this change, every batchbuffer can use all available fences (save
    pinned and scanout, of course) without ever stalling the gpu!
    
    In theory. Currently the actual pipelined update of the register is
    disabled due to some stability issues. However, just the deferred update
    is a significant win.
    
    Based on a series of patches by Daniel Vetter.
    
    The premise is that before every access to a buffer through the GTT we
    have to declare whether we need a register or not. If the access is by
    the GPU, a pipelined update to the register is made via the ringbuffer,
    and we track the last seqno of the batches that access it. If by the
    CPU we wait for the last GPU access and update the register (either
    to clear or to set it for the current buffer).
    
    One advantage of being able to pipeline changes is that we can defer the
    actual updating of the fence register until we first need to access the
    object through the GTT, i.e. we can eliminate the stall on set_tiling.
    This is important as the userspace bo cache does not track the tiling
    status of active buffers which generate frequent stalls on gen3 when
    enabling tiling for an already bound buffer.
    Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    d9e86c0e
i915_gem_execbuffer.c 31.1 KB