From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: Use the correct plane stride
Date: Fri, 3 Jul 2020 14:38:52 +0300 [thread overview]
Message-ID: <20200703113852.GL6112@intel.com> (raw)
In-Reply-To: <a3d6b78b881a1fd554c12f247ecd8cbfa8106faf.camel@intel.com>
On Thu, Jul 02, 2020 at 11:24:04PM +0000, Souza, Jose wrote:
> On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Consult the actual plane stride instead of the fb stride. The two
> > will disagree when we remap the gtt. The plane stride is what the
> > hw will be fed so that's what we should look at for the FBC
> > retrictions/cfb allocation.
> >
> > Since we no longer require a fence we are going to attempt using
> > FBC with remapping, and so we should look at correct stride.
> >
> > With 90/270 degree rotation the plane stride is stored in units
> > of pixels, so we need to conver it to bytes for the purposes
> > of calculating the cfb stride. Not entirely sure if this matches
> > the hw behaviour though. Need to reverse engineer that at some
> > point...
> >
> > We also need to reorder the pixel format check vs. stride check
> > to avoid triggering a spurious WARN(stride & 63) with cpp==1 and
> > plane stride==32.
> >
> > v2: Try to deal with rotated stride and related WARN
> >
>
> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
>
> > Cc: José Roberto de Souza <jose.souza@intel.com>
> > Fixes: 691f7ba58d52 ("drm/i915/display/fbc: Make fences a nice-to-have for GEN9+")
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 16 ++++++++++------
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 69a0682ddb6a..d30c2a389294 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -695,9 +695,13 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> > cache->plane.pixel_blend_mode = plane_state->hw.pixel_blend_mode;
> >
> > cache->fb.format = fb->format;
> > - cache->fb.stride = fb->pitches[0];
> > cache->fb.modifier = fb->modifier;
> >
> > + /* FIXME is this correct? */
> > + cache->fb.stride = plane_state->color_plane[0].stride;
> > + if (drm_rotation_90_or_270(plane_state->hw.rotation))
>
> If it was wrong our CI would caught this in BDW or SNB for example.
Not really. Well, certainly not on pre-skl since they don't do 90/270
rotation. And probably not even on skl+ since any wrong assumption
about how the cfb stride is calculated by the hw would just cause it
to scribble over stolen memory we didn't allocate. So unless we've
started to use stolen more extensively in recent times such problems
would probably go unnoticed.
>
> > + cache->fb.stride *= fb->format->cpp[0];
> > +
> > /* FBC1 compression interval: arbitrary choice of 1 second */
> > cache->interval = drm_mode_vrefresh(&crtc_state->hw.adjusted_mode);
> >
> > @@ -797,6 +801,11 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > return false;
> > }
> >
> > + if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
> > + fbc->no_fbc_reason = "pixel format is invalid";
> > + return false;
> > + }
> > +
> > if (!rotation_is_valid(dev_priv, cache->fb.format->format,
> > cache->plane.rotation)) {
> > fbc->no_fbc_reason = "rotation unsupported";
> > @@ -813,11 +822,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > return false;
> > }
> >
> > - if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
> > - fbc->no_fbc_reason = "pixel format is invalid";
> > - return false;
> > - }
> > -
> > if (cache->plane.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
> > cache->fb.format->has_alpha) {
> > fbc->no_fbc_reason = "per-pixel alpha blending is incompatible with FBC";
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-07-03 11:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 15:37 [Intel-gfx] [PATCH 0/4] drm/i915: FBC fixes Ville Syrjala
2020-07-02 15:37 ` [Intel-gfx] [PATCH 1/4] drm/i915/fbc: Use the correct plane stride Ville Syrjala
2020-07-02 23:24 ` Souza, Jose
2020-07-03 11:38 ` Ville Syrjälä [this message]
2020-07-06 20:53 ` Souza, Jose
2020-07-07 12:24 ` Ville Syrjälä
2020-07-07 0:37 ` Rodrigo Vivi
2020-07-02 15:37 ` [Intel-gfx] [PATCH 2/4] drm/i915/fbc: Fix nuke for pre-snb platforms Ville Syrjala
2020-07-02 23:02 ` Souza, Jose
2020-07-03 11:45 ` Ville Syrjälä
2020-07-02 15:37 ` [Intel-gfx] [PATCH 3/4] drm/i915/fbc: Enable fbc on i865 Ville Syrjala
2020-07-02 22:06 ` Souza, Jose
2020-07-02 15:37 ` [Intel-gfx] [PATCH 4/4] drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865 Ville Syrjala
2020-07-02 22:22 ` Souza, Jose
2020-07-02 16:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: FBC fixes (rev3) Patchwork
2020-07-02 22:02 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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=20200703113852.GL6112@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jose.souza@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.