| Message ID | 1448786893-2522-14-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 29/11/15 08:48, Chris Wilson wrote: > We have testcases to ensure that seqno wraparound works fine, so we can > forgo forcing everyone to encounter seqno wraparound during early > uptime. seqno wraparound incurs a full GPU stall so not forcing it > will eliminate one jitter from the early system. > > Advancing the global next_seqno after a GPU reset is equally pointless. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> The real bug is that seqno wraparound forces GPU idle, can we fix that instead? .Dave.
On Tue, Dec 01, 2015 at 04:57:11PM +0000, Dave Gordon wrote: > On 29/11/15 08:48, Chris Wilson wrote: > >We have testcases to ensure that seqno wraparound works fine, so we can > >forgo forcing everyone to encounter seqno wraparound during early > >uptime. seqno wraparound incurs a full GPU stall so not forcing it > >will eliminate one jitter from the early system. > > > >Advancing the global next_seqno after a GPU reset is equally pointless. > > > >Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > The real bug is that seqno wraparound forces GPU idle, can we fix that > instead? hw semaphores will fall over if we don't, but I guess we can forgo the idle if there's no hw semaphores enabled. And yeah I'd like to keep this little trick to exercise wrap-around more often too. -Daniel
On Fri, Dec 04, 2015 at 10:36:45AM +0100, Daniel Vetter wrote: > On Tue, Dec 01, 2015 at 04:57:11PM +0000, Dave Gordon wrote: > > On 29/11/15 08:48, Chris Wilson wrote: > > >We have testcases to ensure that seqno wraparound works fine, so we can > > >forgo forcing everyone to encounter seqno wraparound during early > > >uptime. seqno wraparound incurs a full GPU stall so not forcing it > > >will eliminate one jitter from the early system. > > > > > >Advancing the global next_seqno after a GPU reset is equally pointless. > > > > > >Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > > > The real bug is that seqno wraparound forces GPU idle, can we fix that > > instead? > > hw semaphores will fall over if we don't, but I guess we can forgo the > idle if there's no hw semaphores enabled. And yeah I'd like to keep this > little trick to exercise wrap-around more often too. But we have a test case that you can run as often as you like as part of CI setup even, to set the wraparound to happen at a psuedo-random location during the testing. -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 0cfdd971e8d7..2c3e36e19cb0 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4774,14 +4774,6 @@ i915_gem_init_hw(struct drm_device *dev) } } - /* - * Increment the next seqno by 0x100 so we have a visible break - * on re-initialisation - */ - ret = i915_gem_set_seqno(dev, dev_priv->next_seqno+0x100); - if (ret) - goto out; - /* Now it is safe to go back round and do everything else: */ for_each_ring(ring, dev_priv, i) { struct drm_i915_gem_request *req; @@ -4969,13 +4961,7 @@ i915_gem_load(struct drm_device *dev) dev_priv->num_fence_regs = I915_READ(vgtif_reg(avail_rs.fence_num)); - /* - * Set initial sequence number for requests. - * Using this number allows the wraparound to happen early, - * catching any obvious problems. - */ - dev_priv->next_seqno = ((u32)~0 - 0x1100); - dev_priv->last_seqno = ((u32)~0 - 0x1101); + dev_priv->next_seqno = 1; /* Initialize fence registers to zero */ INIT_LIST_HEAD(&dev_priv->mm.fence_list);
We have testcases to ensure that seqno wraparound works fine, so we can forgo forcing everyone to encounter seqno wraparound during early uptime. seqno wraparound incurs a full GPU stall so not forcing it will eliminate one jitter from the early system. Advancing the global next_seqno after a GPU reset is equally pointless. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-)