From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 8/9] drm/i915: Hook up dirtyfb ioctl for FBC nuke Date: Mon, 25 Nov 2013 09:46:07 +0100 Message-ID: <20131125084607.GT27344@phenom.ffwll.local> References: <1385062193-19466-1-git-send-email-ville.syrjala@linux.intel.com> <1385062193-19466-9-git-send-email-ville.syrjala@linux.intel.com> <20131121231802.GA4166@nuc-i3427.alporthouse.com> <20131122151901.GE10036@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by gabe.freedesktop.org (Postfix) with ESMTP id 91A05FA6C4 for ; Mon, 25 Nov 2013 00:45:28 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so3438026wgg.28 for ; Mon, 25 Nov 2013 00:45:26 -0800 (PST) Content-Disposition: inline In-Reply-To: <20131122151901.GE10036@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Nov 22, 2013 at 05:19:01PM +0200, Ville Syrj=E4l=E4 wrote: > On Thu, Nov 21, 2013 at 11:18:02PM +0000, Chris Wilson wrote: > > On Thu, Nov 21, 2013 at 09:29:52PM +0200, ville.syrjala@linux.intel.com= wrote: > > > From: Ville Syrj=E4l=E4 > > > = > > > FBC host modification tracking only works through GTT mmaps, so any > > > direct CPU access needs to manually nuke the compressed framebuffer > > > on modifications. Hook up the dirtyfb ioctl to do just that. > > = > > But direct CPU access (not GTT) notification is done through SW_FINISH > > ioctl. Overzealously nuking FBC here makes it inconvenient for userpsace > > to use fb_dirty as part of its periodic-flush-scanout procedure. > = > I see. I can move the fbc nuke to sw_finish. Could we actually document > the rules for these ioctls somewhere? Yeah, I'll do that when reviewing your testcase. Imo we should have two subtests for each access method: One with the legacy way of doing things (where we only care about correctness and could e.g. opt to completely nuke things), one using drmDirtyFb (if we decide to go down this road). Note that imo drmDirtyFB is only useful if we decide to ditch the hw based tracking and go with sw tracking. Otherwise we start to sprinkle usage all over the place, which means we're probably doing something stupid (which is caught by the hw tracking for now). That usually leads to baked-in abi stupidity for the next few years ;-) -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch