[Intel-gfx] [PATCH 3/6] drm/i915: Don't emit semaphore wait if wrap happened

Chris Wilson chris at chris-wilson.co.uk
Thu Dec 6 13:24:04 CET 2012


On Thu, 6 Dec 2012 13:14:09 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Dec 6, 2012 at 12:41 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
> > 2012/12/6 Daniel Vetter <daniel at ffwll.ch>:
> >> On Wed, Dec 5, 2012 at 9:44 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
> >>> 2012/12/4 Mika Kuoppala <mika.kuoppala at linux.intel.com>:
> >>>> If wrap just happened we need to prevent emitting waits for
> >>>> pre wrap values. Detect this and emit no-ops instead.
> >>>>
> >>>> v2: Use olr > seqno to detect wrap instead of *seqno == 0
> >>>> as suggested by Chris Wilson.
> >>>
> >>> This commit introduces a bug on Haswell. Now when I'm typing my
> >>> password on GDM the screen keeps doing wrong rendering. It "blinks
> >>> blue". After logging in I don't see more prodrm/i915: Set initial seqno value close to wrap boundaryblems.
> >>
> >> Just now I've taken out "drm/i915: Set initial seqno value close to
> >> wrap boundary" since QA complained that it regresses things. Does that
> >> help for you, too?
> >
> > It helps: besides the "wrong rendering at GDM screen" I was also
> > getting  GPU hangs (when starting X, when running dmesg, when alt+tab,
> > etc), and it seems with today's dinq I don't get the gpu hangs
> > anymore. I still get the "wrong rendering" problem and it goes away if
> > we revert the "Don't emit semaphore wait  if wrap happened".
> 
> Ok, looks like we have still some fish left to fry here. I've backed
> out the 2nd patch, too. And I guess we need some more tests in i-g-t
> to check semaphore correctness, we seem to have some serious gaps ...

I wouldn't back that out too quickly as it seems that Paulo has some
debugging to do first. A few WARNs would be a good start...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list