[Intel-gfx] [PATCH 1/4] drm/i915: Track fence setup separately from fenced object lifetime
Daniel Vetter
daniel at ffwll.ch
Sat Mar 19 23:35:55 CET 2011
On Fri, Mar 18, 2011 at 10:35:16PM +0000, Chris Wilson wrote:
> This fixes a bookkeeping error causing an OOPS whilst waiting for an
> object to finish using a fence. Now we can simply wait for the fence to
> be written independent of the objects currently inhabiting it (past,
> present and future).
Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Ah, this patch addresses my update label comment ;) Otherwise I think
tracking fences more as independent objects definitely results in clearer
semantics. A tiny nitpick below.
> @@ -2647,9 +2638,13 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj,
> pipelined = NULL;
>
> old->fence_reg = I915_FENCE_REG_NONE;
> - old->last_fenced_ring = pipelined;
> - old->last_fenced_seqno =
> - pipelined ? i915_gem_next_request_seqno(pipelined) : 0;
> + old->last_fenced_seqno = 0;
> + if (pipelined) {
> + old->last_fenced_seqno =
> + i915_gem_next_request_seqno(pipelined);
> + i915_gem_object_move_to_active(old, pipelined,
> + old->last_fenced_seqno);
> + }
>
> drm_gem_object_unreference(&old->base);
> } else if (obj->last_fenced_seqno == 0)
This special case of the last_fenced_seqno tracking slightly annoys me. I
_think_ the flush_ring in flush_fence does already take care of this (but
I'm not too shure, and this is definitely the safe option).
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the Intel-gfx
mailing list