Chris Wilson <[email protected]> writes: > We pre-increment the timeline->seqno when handing it to the request, > make sure the GEM_TRACE takes this into account. Otherwise, it appears > that we go backwards over a preemption point: > > 1d..1 157681077us : __i915_request_unsubmit: vcs0 fence 75e:3 <- global_seqno > 17 > 0d.s1 157681113us : __i915_request_submit: vcs0 fence 75e:3 -> global_seqno 16 > > Fixes: d9b13c4dde6c ("drm/i915: Trace GEM steps between submit and wedging") > Signed-off-by: Chris Wilson <[email protected]> > Cc: Mika Kuoppala <[email protected]> > Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]> > --- > drivers/gpu/drm/i915/i915_request.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 2325886d1d55..f1b81fe4f9ab 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -501,7 +501,7 @@ void __i915_request_submit(struct i915_request *request) > GEM_TRACE("%s fence %llx:%d -> global_seqno %d\n", > request->engine->name, > request->fence.context, request->fence.seqno, > - engine->timeline->seqno); > + engine->timeline->seqno + 1); > > GEM_BUG_ON(!irqs_disabled()); > lockdep_assert_held(&engine->timeline->lock); > -- > 2.16.2 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
