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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx wrote:
> > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > 
> > > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux