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
