On Mon, Nov 25, 2013 at 11:04:48AM +0000, Chris Wilson wrote: > On Mon, Nov 25, 2013 at 09:47:28AM +0100, Daniel Vetter wrote: > > On Thu, Nov 21, 2013 at 11:20:58PM +0000, Chris Wilson wrote: > > > On Thu, Nov 21, 2013 at 09:29:53PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > Flush the caches when moving a scanout buffer from CPU to GTT domain. > > > > This allows us to move a scanout buffer to CPU write domain, do some > > > > writes, and move it back to the GTT read domain. The display will then > > > > see the correct data. In addition we still need to do the dirtyfb > > > > ioctl to nuke FBC if that's enabled. > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Isn't this what sw_finish is for? > > I was more concerned about making sure the code was reasonably > self-consistent in applying our own coherency rules. As you point out, > it may be userspace making a mistake, but so many paths can end up here, > and almost never have pin_display, that it would seem to be preferrable > to do the extra flush rather than have the discrepancy. If we don't do the flush in CPU->GTT move, we might miss it completely. Eg. if we do things in this order: set_domain(CPU,CPU) write some data set_domain(GTT,0) sw_finish() sw_finish would not do the flush since the object is no longer in the CPU write domain. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
