On Thu, Mar 24, 2016 at 09:21:49PM +0000, Zanoni, Paulo R wrote: > Em Qui, 2016-03-24 às 21:03 +0000, chris@xxxxxxxxxxxxxxxxxx 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
