All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Revoke partial fences when installing on the scanout
Date: Tue, 27 Dec 2016 15:52:32 +0100	[thread overview]
Message-ID: <20161227145232.GE31952@dvetter-linux.ger.corp.intel.com> (raw)
In-Reply-To: <1482439179.2641.71.camel@intel.com>

On Thu, Dec 22, 2016 at 06:39:39PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-12-22 às 13:52 +0000, Chris Wilson escreveu:
> > In commit 50349247ea80 ("drm/i915: Drop ORIGIN_GTT for untracked GTT
> > writes") partial mmaps were updated to indicate that writes through
> > them
> > were not tracked automatically by the hardware and that the expected
> > subsequent manual invalidations by the application (on calling
> > dirtyfb at
> > the end of the frame) take over from the hardware tracking. However,
> > not
> > all applications actually call dirtyfb on the scanout after they
> > dirty it
> > and so those writes through partial GTT mmaps are not being tracked
> > and
> > triggering FBC updates.
> 
> Since the application in question here is IGT, and IGT is generally not
> considered a real API/ABI user to enforce backwards compatibility
> forever, I can make the required changes to IGT in case we conclude
> that's the appropriate way to go, just tell me. But if that's the case,
> I really think we should try to sit down and write what are the
> expectations for frontbuffer rendering in user space code, because it
> seems to me that these expectations are changing over time...

Yeah, same here. Afaiui it's not resulting in any functional issues (like
outdated screen contents), just fbc not gettting re-enabled. I think just
expecting all userspace that cares to call dirtyfb, and adjusting IGT is
the more reasonable option. We're still making a best effort at keeping
fbc working for userspace that doesn't, but trying to make it perfect is
probably a long game of whack-a-mole. I don't think that's worth it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      parent reply	other threads:[~2016-12-27 14:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-22 13:52 [PATCH] drm/i915: Revoke partial fences when installing on the scanout Chris Wilson
2016-12-22 15:26 ` Chris Wilson
2016-12-22 20:39 ` Paulo Zanoni
2016-12-22 21:07   ` Chris Wilson
2016-12-27 14:52   ` Daniel Vetter [this message]

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=20161227145232.GE31952@dvetter-linux.ger.corp.intel.com \
    --to=daniel@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.