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

Zanoni, Paulo R paulo.r.zanoni at intel.com
Thu Mar 24 20:53:21 UTC 2016

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.

> -Chris

More information about the Intel-gfx mailing list