On Tue, Aug 06, 2013 at 10:08:38PM +0300, Ville Syrjälä wrote: > On Tue, Aug 06, 2013 at 07:45:40PM +0100, Chris Wilson wrote: > > On Tue, Aug 06, 2013 at 09:03:01PM +0300, Ville Syrjälä wrote: > > > On Tue, Aug 06, 2013 at 05:16:14PM +0100, Chris Wilson wrote: > > > > On Tue, Aug 06, 2013 at 05:24:25PM +0300, Ville Syrjälä wrote: > > > > > Also i915_gem_sw_finish_ioctl() still looks at pin_count as an > > > > > indication whether scanout is happening. We should add an fb_count > > > > > check there as well. Maybe we should leave the pin_count check there, > > > > > so that framebuffers that aren't being scanned out currently can be > > > > > massaged a bit more freely before a clflush needs to be issued? > > > > > > > > It does do a fb_count check, the pin_count + fb_count is a really strong > > > > indicator of active scanout. > > > > > > The fb_count checks is done only through the eventual check in > > > i915_gem_clflush_object() which is why I didn't think of it. > > > > > > On non-LLC platforms it also ends up doing the flush for all > > > non-snooped non-scanout buffers, which would get optimized away if the > > > fb_count check was where the pin_count check is. > > > > But it does still do the fb_count check before the flush? What am I > > missing here? > > I believe the code now ends up doing this (on non-LLC): > if (pin_count && (cache_level == UC || fb_count > 0) && write_domain == CPU) > clflush(); > > So it'll flush also all pinned non-snooped buffers whether they be > scanout or not. We could delay such flushes until the bo gets > moved away from the CPU write domain. But maybe it's just a nonsense > scenario. Why would someone write to a pinned bo unless the pinning is > due to scanout? Right. So long as this patch doesn't make it any worse than clflushing all pinned objects, I'm inclined to consider it an improvement. The final step to only clflushing when attached to an active CRTC is an optimisation made in the frontbuffer tracking series. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
