public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 8/9] drm/i915: Hook up dirtyfb ioctl for FBC nuke
Date: Mon, 25 Nov 2013 09:46:07 +0100	[thread overview]
Message-ID: <20131125084607.GT27344@phenom.ffwll.local> (raw)
In-Reply-To: <20131122151901.GE10036@intel.com>

On Fri, Nov 22, 2013 at 05:19:01PM +0200, Ville Syrjälä 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älä <ville.syrjala@linux.intel.com>
> > > 
> > > 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

  reply	other threads:[~2013-11-25  8:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-21 19:29 [PATCH 0/9] drm/i915: Some more FBC stuff ville.syrjala
2013-11-21 19:29 ` [PATCH 1/9] drm/i915: Don't set the fence number in DPFC_CTL on SNB ville.syrjala
2013-11-21 23:22   ` Chris Wilson
2013-11-25  8:43     ` Daniel Vetter
2013-11-21 19:29 ` [PATCH 2/9] drm/i915: Don't set persistent FBC mode on ILK/SNB ville.syrjala
2013-11-21 19:29 ` [PATCH 3/9] drm/i915: Don't set DPFC_HT_MODIFY bit on CTG/ILK/SNB ville.syrjala
2013-11-21 19:29 ` [PATCH 4/9] drm/i915: Use LRI based FBC render tracking for ILK ville.syrjala
2013-11-27 15:24   ` [PATCH v2 " ville.syrjala
2013-11-28 11:29     ` Chris Wilson
2013-11-21 19:29 ` [PATCH 5/9] drm/i915: Reorder i915_gem_execbuffer_move_to_gpu() and i915_switch_context() ville.syrjala
2013-11-21 19:29 ` [PATCH 6/9] drm/i915: Improve page flip vs. FBC interaction ville.syrjala
2013-11-21 19:29 ` [PATCH 7/9] drm: Push dirtyfb ioctl kms locking down to drivers ville.syrjala
2013-12-03 21:38   ` Daniel Vetter
2013-11-21 19:29 ` [PATCH 8/9] drm/i915: Hook up dirtyfb ioctl for FBC nuke ville.syrjala
2013-11-21 23:18   ` Chris Wilson
2013-11-22 15:19     ` Ville Syrjälä
2013-11-25  8:46       ` Daniel Vetter [this message]
2013-11-25 14:54     ` [PATCH v2 8/9] drm/i915: Nuke FBC from SW_FINISH ioctl ville.syrjala
2013-11-25 15:04       ` Chris Wilson
2013-11-25 15:19         ` [PATCH v3 " ville.syrjala
2013-12-04 16:28           ` [PATCH v4 " ville.syrjala
2013-11-21 19:29 ` [PATCH 9/9] drm/i915: Flush caches for scanout during cpu->gtt move ville.syrjala
2013-11-21 23:20   ` Chris Wilson
2013-11-25  8:47     ` Daniel Vetter
2013-11-25 11:04       ` Chris Wilson
2013-11-25 14:40         ` Ville Syrjälä
2013-11-25 15:12           ` Daniel Vetter
2013-12-03 21:42 ` [PATCH 0/9] drm/i915: Some more FBC stuff Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131125084607.GT27344@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox