[Intel-gfx] [PATCH 8/9] drm/i915: Hook up dirtyfb ioctl for FBC nuke

Daniel Vetter daniel at ffwll.ch
Mon Nov 25 09:46:07 CET 2013


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 at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at 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



More information about the Intel-gfx mailing list