From: Daniel Vetter <daniel@ffwll.ch>
To: ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 06/12] drm/i915: Adjust obj tiling vs. fb modifier rules
Date: Wed, 10 Aug 2016 11:43:27 +0200 [thread overview]
Message-ID: <20160810094327.GT6232@phenom.ffwll.local> (raw)
In-Reply-To: <1470821001-25272-7-git-send-email-ville.syrjala@linux.intel.com>
On Wed, Aug 10, 2016 at 12:23:15PM +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Currently we require the object to be X tiled if the fb is X
> tiled. The argument is supposedly FBC GTT tracking. But
> actually that no longer holds water since FBC supports
> Y tiling as well on SKL+.
>
> A better rule IMO is to require that if there is a fence, the
> fb modifier match the object tiling mode. But if the object is linear,
> we can allow the fb modifier to be anything. The idea being that
> if the user set the tiling mode on the object, presumably the intention
> is to actually use the fence for CPU access. But if the tiling mode is
> not set, the user has no intention of using a fence (and can't actually
> since we disallow tiling mode changes when there are framebuffers
> associated with the object).
>
> On gen2/3 we must keep to the rule that the object and fb
> must be either both linear or both X tiled. No mixing allowed
> since the display engine itself will use the fence if it's present.
>
> v2: Fix typos
> v3: Rebase due to i915_gem_object_get_tiling() & co.
>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
So the reason why I didn't like this is that it makes the fbc checking
more tricky. Someone might think that checking for X-tiling on just the
drm_framebuffer is good enough and then we'd have some potentially funny
bugs. But the fbc code still only looks at the gem bo tiling, so all is
still fine.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/i915/intel_display.c | 31 ++++++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index d8855ba969be..ad9f8b303fbc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15150,23 +15150,26 @@ static int intel_framebuffer_init(struct drm_device *dev,
> struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> + unsigned int tiling = i915_gem_object_get_tiling(obj);
> int ret;
> u32 pitch_limit, stride_alignment;
>
> WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>
> if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
> - /* Enforce that fb modifier and tiling mode match, but only for
> - * X-tiled. This is needed for FBC. */
> - if (!!(i915_gem_object_get_tiling(obj) == I915_TILING_X) !=
> - !!(mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED)) {
> + /*
> + * If there's a fence, enforce that
> + * the fb modifier and tiling mode match.
> + */
> + if (tiling != I915_TILING_NONE &&
> + tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
> return -EINVAL;
> }
> } else {
> - if (i915_gem_object_get_tiling(obj) == I915_TILING_X)
> + if (tiling == I915_TILING_X) {
> mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
> - else if (i915_gem_object_get_tiling(obj) == I915_TILING_Y) {
> + } else if (tiling == I915_TILING_Y) {
> DRM_DEBUG("No Y tiling for legacy addfb\n");
> return -EINVAL;
> }
> @@ -15190,6 +15193,16 @@ static int intel_framebuffer_init(struct drm_device *dev,
> return -EINVAL;
> }
>
> + /*
> + * gen2/3 display engine uses the fence if present,
> + * so the tiling mode must match the fb modifier exactly.
> + */
> + if (INTEL_INFO(dev_priv)->gen < 4 &&
> + tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> + DRM_DEBUG("tiling_mode must match fb modifier exactly on gen2/3\n");
> + return -EINVAL;
> + }
> +
> stride_alignment = intel_fb_stride_alignment(dev_priv,
> mode_cmd->modifier[0],
> mode_cmd->pixel_format);
> @@ -15209,7 +15222,11 @@ static int intel_framebuffer_init(struct drm_device *dev,
> return -EINVAL;
> }
>
> - if (mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED &&
> + /*
> + * If there's a fence, enforce that
> + * the fb pitch and fence stride match.
> + */
> + if (tiling != I915_TILING_NONE &&
> mode_cmd->pitches[0] != i915_gem_object_get_stride(obj)) {
> DRM_DEBUG("pitch (%d) must match tiling stride (%d)\n",
> mode_cmd->pitches[0],
> --
> 2.7.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
next prev parent reply other threads:[~2016-08-10 9:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-10 9:23 [PATCH v5 00/12] drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v5) ville.syrjala
2016-08-10 9:23 ` [PATCH v6 01/12] drm/i915: Rewrite fb rotation GTT handling ville.syrjala
2016-08-10 9:49 ` Daniel Vetter
2016-08-10 9:23 ` [PATCH v3 02/12] drm/i915: Don't pass pitch to intel_compute_page_offset() ville.syrjala
2016-08-10 9:23 ` [PATCH v2 03/12] drm/i915: Move SKL hw stride calculation into a helper ville.syrjala
2016-08-10 9:23 ` [PATCH 04/12] drm/i915: Pass around plane_state instead of fb+rotation ville.syrjala
2016-08-10 9:23 ` [PATCH v4 05/12] drm/i915: Use fb modifiers for display tiling decisions ville.syrjala
2016-08-10 9:23 ` [PATCH v3 06/12] drm/i915: Adjust obj tiling vs. fb modifier rules ville.syrjala
2016-08-10 9:43 ` Daniel Vetter [this message]
2016-08-10 9:23 ` [PATCH v2 07/12] drm/i915: Limit fb x offset due to fences ville.syrjala
2016-08-10 9:23 ` [PATCH 08/12] drm/i915: Allow calling intel_adjust_tile_offset() multiple times ville.syrjala
2016-08-10 9:46 ` Chris Wilson
2016-08-10 9:48 ` Daniel Vetter
2016-08-10 11:17 ` Ville Syrjälä
2016-08-10 9:23 ` [PATCH 09/12] drm/i915: Make intel_adjust_tile_offset() work for linear buffers ville.syrjala
2016-08-10 9:23 ` [PATCH v2 10/12] drm/i915: Compute display surface offset in the plane check hook for SKL+ ville.syrjala
2016-08-10 9:23 ` [PATCH v2 11/12] drm/i915: Deal with NV12 CbCr plane AUX surface on SKL+ ville.syrjala
2016-08-10 10:03 ` Daniel Vetter
2016-08-10 11:26 ` Ville Syrjälä
2016-08-10 9:23 ` [PATCH v2 12/12] drm/i915: Make sure fb offset is (macro)pixel aligned ville.syrjala
2016-08-10 10:04 ` Daniel Vetter
2016-08-10 11:02 ` Ville Syrjälä
2016-08-10 11:33 ` Ville Syrjälä
2016-08-11 16:37 ` Ville Syrjälä
2016-08-10 11:46 ` ✗ Ro.CI.BAT: failure for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v5) Patchwork
2016-08-10 12:40 ` Ville Syrjälä
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=20160810094327.GT6232@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.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