On Mon, Mar 04, 2013 at 03:51:11PM +0200, Ville Syrj?l? wrote: > On Sun, Mar 03, 2013 at 05:39:09PM +0000, Chris Wilson wrote: > > On Sun, Mar 03, 2013 at 05:28:52PM +0100, Daniel Vetter wrote: > > > The other thing was that I didn't manage to get things to work properly, > > > leaving some random cachline dirt on the screen. Looking at your code, you > > > add the gfdt flush to every ring_flush, whereas I've tried to be clever > > > and only flushed after batches rendering to the frontbuffer. So probably a > > > bug in my code, or a flush on a given ring doesn't flush out caches for > > > one of the other engines. > > > > Right, we have a formalized interface for flushes to scanout rather than > > always flushing GFDT. > > We do? Where's that? A side-effect of the API for busy_ioctl() is that all caches for the bo are flushed and any outstanding requests queued in order for the bo to become unbusy in the near-future. This semantic was required for GL query objects to eventually complete without futher interaction. It also solved the problem of having to flush the scanout periodically on gen4+ (and on gen3 if we enable the optimisation bit) and is so enshrined into lore. -Chris -- Chris Wilson, Intel Open Source Technology Centre
