Re: [PATCH] drm/i915: Set DERRMR around batches required vblank events

[Chris Wilson <chris@chris-wilson.co.uk>]

On Tue, 16 Oct 2012 16:15:40 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Oct 16, 2012 at 11:47 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > I am still not convinced this fixes anything as at the moment I am
> > simply unable to detect any tearing on my ivb setup if I apply any form of
> > vblank throttling.
> >
> > The other issue is that I think if I had a SECURE
> > (DRM_MASTER|DRM_ROOT_ONLY) batch buffer I could probably do all of this
> > in userspace.
> 
> Yeah, I'm a bit torn between this approach and just allowing SECURE
> batches. The big upside of secure batches is that it allows more
> flexibility (if the LRI really work from secure batches and not just
> from the ring). The only downside I can see is that we won't be able
> to arbitrage the derrmr bits (since only one is allowed to be set at
> any given time) between different userspace processes. But I don't see
> mutliple concurrent display servers (with cooperative owenership of
> the hw) happening anytime soon, so I won't worry about this before it
> happens. Syncing against modeset should still work with our MI_WAIT
> related waits on fbs before we disable the pipe.

Ok, so it seems that with a SECURE batch buffer and the kernel fixing up
the gGTT-vs-ppGTT mess, it is very easy to program a scanline wait. (I
still haven't convinced myself that it does eliminate tearing, as even
without vsync my usual tricks to reproduce tearing work fine.)

Being the ego-centric user that I am, I have no qualms about making
SECURE batches MASTER|ROOT_ONLY to limit the possibility of someone
leaving the hardware in an undefined state.

> The other issue (only on gen7) is that this will keep the gpu out of
> rc6 (and hence the entire package) for long times, especially on
> mostly-idle video playback. I don't think that massively increased
> power consumption is what users will appreciated.

Yes, not much I can do about that, other than hope everyone migrates
over to a sane pageflipping architecture for their video playback. For
the rest, we just have to make sure TearFree delivers low power
consumption on future hardware.
 
> Now with the Tearfree option and you saying that vblank render
> throttling mostly fixes this, do we have any unhappy bug reporters
> left? In that case I'd prefer to just can this entirely (and suggest
> to ppl to use a real compositor - the wasted bw issue on X also seems
> to be on track to be solved).

Looking at the SECURE batches feature, I think that is a fair compromise
for enabling legacy features on current platforms. It should also prove
useful elsewhere, so I think it will stand the test of time. And in the
meantime we can continue to encourage users to migrate away the power
hungry applications.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre