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

[Zanoni, Paulo R]

Em Qui, 2016-03-24 às 21:03 +0000, chris at chris-wilson.co.uk escreveu:
> 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.

I don't recall this being said in the earlier conversations, but now
that you point it, it can be done. Also, we recently pinged/emailed you
many times about this problem, so I wonder why it took you so long to
point this...

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

So at least you agree user space was missing something :)

> -Chris
>