All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, "Satyanantha,
	Rama Gopal M" <rama.gopal.m.satyanantha@intel.com>,
	Deepak S <deepak.s@linux.intel.com>,
	Damien Lespiau <damien.lespiau@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Paulo Zanoni <przanoni@gmail.com>
Subject: Re: [PATCH v2] drm/i915: Fallback to using unmappable memory for scanout
Date: Fri, 20 Mar 2015 15:36:29 +0100	[thread overview]
Message-ID: <20150320143629.GP1349@phenom.ffwll.local> (raw)
In-Reply-To: <20150320104919.GD10812@nuc-i3427.alporthouse.com>

On Fri, Mar 20, 2015 at 10:49:19AM +0000, Chris Wilson wrote:
> On Fri, Mar 20, 2015 at 11:29:25AM +0100, Daniel Vetter wrote:
> > On Thu, Mar 19, 2015 at 04:50:22PM +0000, Chris Wilson wrote:
> > > On Thu, Mar 19, 2015 at 05:35:17PM +0100, Daniel Vetter wrote:
> > > > On Thu, Mar 19, 2015 at 11:29:40AM +0000, Chris Wilson wrote:
> > > > > +	if (obj->map_and_fenceable) {
> > > > > +		/* Install a fence for tiled scan-out. Pre-i965 always needs a
> > > > > +		 * fence, whereas 965+ only requires a fence if using
> > > > > +		 * framebuffer compression.  For simplicity, we always, when
> > > > > +		 * possible, install a fence as the cost is not that onerous.
> 
> > Oh right I've forgotten that fbc hw only works with X tiled and that we
> > use the fence_reg as a proxy. Adding a comment would be useful though.
> 
> * If we fail to fence the tiled scanout, then either the modeset will
> * reject the change (which is highly unlikely as the affected systems,
> * all but one, do not have unmappable space) or we will not be able to
> * enable full powersaving techniques (also likely not to apply due to
> * various limits FBC and the like impose on the size of the buffer,
> * which presumably we violated anyway with this unmappable buffer).
> * Anyway, it is presumably better to stumble onwards with something and
> * try to run the system in a "less than optimal" mode that matches the
> * user configuration.

I actually thought of a comment in the obj->fence_reg check in the fbc
code that we now can have frontbuffers lacking fences. And that the check
isn't just a proxy check for x-tiled anymore.

Just to avoid someone replacing the obj->fence_reg check with a
obj->tiling_mode == X_TILING check somewhen in the future.

Not fencing here is imo clear, since iirc on gen3 fences in the unmappable
part are not allowed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-03-20 14:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 22:08 [PATCH] drm/i915: Fallback to using unmappable memory for scanout Chris Wilson
2015-03-19 10:53 ` Deepak S
2015-03-19 11:27   ` Chris Wilson
2015-03-19 11:29   ` [PATCH v2] " Chris Wilson
2015-03-19 13:01     ` Deepak S
2015-03-19 13:10       ` Chris Wilson
2015-03-19 13:13         ` Deepak S
2015-03-19 16:34         ` Daniel Vetter
2015-03-19 16:51           ` Chris Wilson
2015-03-19 16:35     ` Daniel Vetter
2015-03-19 16:50       ` Chris Wilson
2015-03-20 10:29         ` Daniel Vetter
2015-03-20 10:49           ` Chris Wilson
2015-03-20 14:36             ` Daniel Vetter [this message]
2015-03-20 14:52           ` Ville Syrjälä
2015-03-19 16:39     ` Damien Lespiau
2015-03-19 16:54       ` Chris Wilson
2015-03-19 21:57     ` shuang.he
2015-03-25 12:21     ` Jani Nikula
2015-03-25 12:40       ` [PATCH v3] " Chris Wilson
2015-03-25 15:07         ` shuang.he
2015-03-25 12:44       ` [PATCH v4] " Chris Wilson
2015-03-25 13:17         ` Daniel Vetter
2015-03-25 17:30         ` shuang.he
2015-03-19 15:34 ` [PATCH] " shuang.he

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=20150320143629.GP1349@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=damien.lespiau@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=deepak.s@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=przanoni@gmail.com \
    --cc=rama.gopal.m.satyanantha@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.