[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 09:21:49PM +0000, Zanoni, Paulo R wrote:
> 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...

All that needed to be said had been, I felt I would have been repeating
myself and earlier discussions.

> > 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 :)

Yes. It has sat there waiting for the missing piece to be added for 3
years. (Almost 3 years, 2 years 9 months.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre