drm/i915: Fix tracing of submit seqno
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: d9b13c4dde
("drm/i915: Trace GEM steps between submit and wedging")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180322110059.4467-1-chris@chris-wilson.co.uk
This commit is contained in:
parent
d544e918ff
commit
0e59c209f4
|
@ -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);
|
||||
|
|
Loading…
Reference in New Issue