From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Set DERRMR around batches required vblank events Date: Wed, 17 Oct 2012 14:58:26 +0100 Message-ID: <275ffc$71du4h@fmsmga002.fm.intel.com> References: <1350380830-26913-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id A9AB6A09B7 for ; Wed, 17 Oct 2012 06:58:46 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, 16 Oct 2012 16:15:40 +0200, Daniel Vetter wrote: > On Tue, Oct 16, 2012 at 11:47 AM, Chris Wilson 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