From: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
To: "chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
Date: Thu, 24 Mar 2016 20:53:21 +0000 [thread overview]
Message-ID: <1458852801.2189.64.camel@intel.com> (raw)
In-Reply-To: <20160324193154.GX27742@nuc-i3427.alporthouse.com>
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-24 20:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 19:16 [PATCH 0/4] Enable FBC on SKL, v2 Paulo Zanoni
2016-03-24 19:16 ` [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes Paulo Zanoni
2016-03-24 19:16 ` [PATCH xf86-video-intel] sna: Opt-out of the Kernel mmap workaround Paulo Zanoni
2016-03-24 19:16 ` [PATCH 2/4] drm/i915/fbc: sanitize i915.enable_fbc during FBC init Paulo Zanoni
2016-03-24 19:16 ` [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC Paulo Zanoni
2016-03-24 19:31 ` Chris Wilson
2016-03-24 20:53 ` Zanoni, Paulo R [this message]
2016-03-24 21:03 ` chris
2016-03-24 21:20 ` chris
2016-03-25 14:05 ` Zanoni, Paulo R
2016-03-25 14:17 ` chris
2016-03-29 11:55 ` Daniel Vetter
2016-03-29 12:24 ` chris
2016-03-24 21:21 ` Zanoni, Paulo R
2016-03-24 21:58 ` chris
2016-03-24 19:16 ` [PATCH 4/4] drm/i915/fbc: enable FBC on gen 9+ too Paulo Zanoni
2016-03-25 9:02 ` ✗ Fi.CI.BAT: failure for sna: Opt-out of the Kernel mmap workaround Patchwork
-- strict thread matches above, loose matches on Subject: below --
2016-03-21 19:26 [PATCH 0/4] Enable FBC on SKL Paulo Zanoni
2016-03-21 19:26 ` [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC Paulo Zanoni
2016-03-22 2:19 ` kbuild test robot
2016-03-22 10:28 ` Jani Nikula
2016-03-22 11:15 ` Daniel Vetter
2016-03-22 13:52 ` Jani Nikula
2016-03-22 11:29 ` Daniel Vetter
2016-03-22 21:48 ` Zanoni, Paulo R
2016-03-23 8:53 ` Daniel Vetter
2016-03-23 16:04 ` Vivi, Rodrigo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1458852801.2189.64.camel@intel.com \
--to=paulo.r.zanoni@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).