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 > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
