On Tue, 16 Oct 2012 16:15:40 +0200, Daniel Vetter <daniel at ffwll.ch> wrote: > On Tue, Oct 16, 2012 at 11:47 AM, Chris Wilson <chris at 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
