All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	"Satyanantha, Rama Gopal M" <rama.gopal.m.satyanantha@intel.com>
Subject: [PATCH v2] drm/i915: Fallback to using unmappable memory for scanout
Date: Thu, 19 Mar 2015 11:29:40 +0000	[thread overview]
Message-ID: <1426764580-26197-1-git-send-email-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <550AAAAC.8000200@linux.intel.com>

The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable region, we are better off just trying to fit it
anywhere and hoping for the best. (Any userspace that is cappable of
using ginormous scanouts is also likely not to rely on pure GTT
updates.) In the future, there may even be a kernel mediated method for
the legacy clients.

v2: Skip fence pinning when not mappable.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Satyanantha, Rama Gopal M <rama.gopal.m.satyanantha@intel.com>
Cc: Deepak S <deepak.s@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem.c      |  7 ++++++-
 drivers/gpu/drm/i915/intel_display.c | 23 +++++++++++++----------
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9e498e0bbf22..9a1de848e450 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4034,10 +4034,15 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
 
 	/* As the user may map the buffer once pinned in the display plane
 	 * (e.g. libkms for the bootup splash), we have to ensure that we
-	 * always use map_and_fenceable for all scanout buffers.
+	 * always use map_and_fenceable for all scanout buffers. However,
+	 * it may simply be too big to fit into mappable, in which case
+	 * put it anyway and hope that userspace can cope (but always first
+	 * try to preserve the existing ABI).
 	 */
 	ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
 	if (ret)
+		ret = i915_gem_obj_ggtt_pin(obj, alignment, 0);
+	if (ret)
 		goto err_unpin_display;
 
 	i915_gem_object_flush_cpu_write_domain(obj);
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index d621ebecd33e..628aace63b43 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2308,16 +2308,18 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
 	if (ret)
 		goto err_interruptible;
 
-	/* 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 install
-	 * a fence as the cost is not that onerous.
-	 */
-	ret = i915_gem_object_get_fence(obj);
-	if (ret)
-		goto err_unpin;
+	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.
+		 */
+		ret = i915_gem_object_get_fence(obj);
+		if (ret)
+			goto err_unpin;
 
-	i915_gem_object_pin_fence(obj);
+		i915_gem_object_pin_fence(obj);
+	}
 
 	dev_priv->mm.interruptible = true;
 	intel_runtime_pm_put(dev_priv);
@@ -2335,7 +2337,8 @@ static void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
 {
 	WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
 
-	i915_gem_object_unpin_fence(obj);
+	if (obj->map_and_fenceable)
+		i915_gem_object_unpin_fence(obj);
 	i915_gem_object_unpin_from_display_plane(obj);
 }
 
-- 
2.1.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-03-19 11:29 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   ` Chris Wilson [this message]
2015-03-19 13:01     ` [PATCH v2] " 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
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=1426764580-26197-1-git-send-email-chris@chris-wilson.co.uk \
    --to=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --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.