[Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

[chris at chris-wilson.co.uk]

On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote:
> Em Qui, 2016-03-24 às 19:31 +0000, Chris Wilson escreveu:
> > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > > 
> > > FBC and the frontbuffer tracking infrastructure were designed
> > > assuming
> > > that user space applications would follow a specific set of rules
> > > regarding frontbuffer management and mmapping. I recently
> > > discovered
> > > that current user space is not exactly following these rules: my
> > > investigation led me to the conclusion that the generic backend
> > > from
> > > SNA - used by SKL and the other new platforms without a specific
> > > backend - is not issuing sw_finish/dirty_fb IOCTLs when using the
> > > CPU
> > > and WC mmaps. I discovered this when running lightdm: I would type
> > > the
> > > password and nothing would appear on the screen unless I moved the
> > > mouse over the place where the letters were supposed to appear.
> > Yes, that is a kernel bug. The protocol we said the kernel would
> > follow
> > is to disable FBC/WC when userspace marks the object for writing by
> > the
> > CPU and would only reestablish FBC/WC upon dirtyfb.
> 
> But on WC mmaps we mark the object for writing by the GTT instead of
> the CPU, and while the tracking engine is able to see "normal" GTT mmap
> writes, it's not able to see WC mmap writes, so we established that
> we'd call dirtyfb after frontbuffer drawing through WC mmaps, which is
> something that the DDX never implemented. This was discussed on #intel-
> gfx on Nov 5 2014, and also possibly other places, but I can't find the
> logs. Daniel also confirmed this to me again on private IRC on Jun 16
> 2015. So I still don't understand why this is a Kernel bug instead of a
> DDX bug.

Because we said that once invalidated, it would not be restored until
dirtyfb. The kernel is not doing that. Your patch does not do that. To
be even close, you should be setting the origin flag based on the existence
of wc mmaping for the object inside set-to-gtt-domain. Otherwise, you
are not implementing even close to the protocol you say you are. That is
invalidate on set-domain, flush on dirtyfb.

The kernel's bug is that is not cancelling FBC. Userspace's bug is not
signalling when to reenable it.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre