Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Apr 19, 2018 at 01:30:32PM +0200, Maarten Lankhorst wrote:
> Op 19-04-18 om 13:22 schreef Ville Syrjälä:
> > On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> >>> Sent: Thursday, April 19, 2018 12:06 AM
> >>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>> Cc: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> >>> gfx@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> >>> skl_check_nv12_surface for NV12
> >>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> >>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> >>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> >>>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
> >>>>>> We skip src trunction/adjustments for
> >>>>>> NV12 case and handle the sizes directly.
> >>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>>>> v2: For NV12, making the src coordinates multiplier of 4
> >>>>>> v3: Moving all the src coords handling code for NV12 to
> >>>>>> skl_check_nv12_surface
> >>>>>> Signed-off-by: Maarten Lankhorst
> >>>>>> <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
> >>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com<mailto:vidya.srinivas@intel.com>>
> >>>>>> ---
> >>>>>>  drivers/gpu/drm/i915/intel_display.c | 39
> >>>>>> ++++++++++++++++++++++++++++++++++++
> >>>>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
> >>>>>>  2 files changed, 50 insertions(+), 4 deletions(-)
> >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> index 925402e..b8dbaca 100644
> >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
> >>> struct intel_crtc_state *crtc_state,
> >>>>>>  return 0;
> >>>>>>  }
> >>>>>> +static int
> >>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >>>>>> +                                       struct intel_plane_state *plane_state) {
> >>>>>> +                int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> >>>>>> +                int crtc_y2 = plane_state->base.crtc_y +
> >>>>>> +plane_state->base.crtc_h;
> >>>>>> +
> >>>>>> +                if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> >>>>>> +                    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> >>>>>> +                    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> >>>>>> +                    ((plane_state->base.src_h >> 16) % 4) != 0) {
> >>>>>> +                                DRM_DEBUG_KMS("src coords must be multiple of 4 for
> >>> NV12\n");
> >>>>>> +                                return -EINVAL;
> >>>>>> +                }
> >>>>> I don't really see why we should check these. The clipped
> >>>>> coordinates are what matters.
> >>>> To propagate our limits to the userspace. I think we should do it for
> >>>> all formats, but NV12 is the first YUV format we have tests for. If we
> >>>> could we should do something similar for the other YUV formats, but they
> >>> have different requirements.
> >>>> In case of NV12 we don't have existing userspace, there will be
> >>>> nothing that breaks if we enforce limits from the start.
> >>> But what about sub-pixel coordinates? You're totally ignoring them here.
> >>> We need to come up with some proper rules for this stuff.
> >>>>>> +
> >>>>>> +                /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> >>>>>> +                if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
> >>> 4) ||
> >>>>>> +                    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
> >>> {
> >>>>>> +                                DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> >>> %u,%u\n",
> >>>>>> +                                                      crtc_x2, crtc_y2,
> >>>>>> +                                                      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> >>>>>> +                                return -EINVAL;
> >>>>>> +                }
> >>>>> Why should we care? The current code already plays it fast and loose
> >>>>> and allows the dst rectangle to shrink to accomodate the hw limits.
> >>>>> If we want to change that we should change it universally.
> >>>> Unfortunately for the other formats we already have an existing
> >>>> userspace
> >>>> (X.org) that doesn't perform any validation. We can't change it for
> >>>> that, but we can prevent future mistakes.
> >>> We should do it uniformly. Not per-format. That will make the code
> >>> unmaintainable real quick.
> >>>>>> +
> >>>>>> +                plane_state->base.src.x1 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
> >>> 18;
> >>>>>> +                plane_state->base.src.x2 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<
> >>> 18;
> >>>>>> +                plane_state->base.src.y1 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<
> >>> 18;
> >>>>>> +                plane_state->base.src.y2 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<
> >>> 18;
> >>>>> Since this can now increase the size of the source rectangle our
> >>>>> scaling factor checks are no longer 100% valid. We might end up with
> >>>>> a scaling factor that is too high.
> >>>>> I don't really like any of these "let's make NV12 behave special"
> >>>>> tricks. We should make the code behave the same way for all pixel
> >>>>> formats instead of adding format specific hacks.
> >>>> This is not nivalid because we restrict the original src coordinates
> >>>> to be a multiple of 4, you can only clip to something smaller, not to
> >>>> something bigger. :)
> >>> The clipped coordinates can be whatever thanks to scaling/etc.
> >>> Also why are we trying to make everything a multiple of four? I don't
> >>> remember any hw restrictions like that.
> >>
> >>
> >> Hi
> >>
> >>
> >> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.
> >>
> >> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.
> > Does plane height here mean src height or dst height?
> >
> > Either way I don't see why we aren't just checking for the right thing
> > instead of trying to mandate a four pixel alignment everywhere.
> >
> Agreed, what about the below diff, would this be acceptable to you? I deliberately ignore the last 16 bits as that is what we currently do anyway for all formats.
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 4b3735720fee..3ff7b5491446 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3090,6 +3090,31 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>  	return 0;
>  }
>  
> +static int
> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> +		       struct intel_plane_state *plane_state)
> +{
> +	/* Display WA #1106 */
> +	if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) &&
> +	    plane_state->base.rotation != DRM_MODE_ROTATE_270)
> +		return 0;

Hmm. I wonder if that's what the spec actually means. The HSDs only
talk about 270 degree rotation. So I guess this interpretation could
be correct.

> +
> +	/* Because x/y are src coordinates will be rotated, we look at x/width here. */
> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_w >> 16) % 4) != 0) {
> +		DRM_DEBUG_KMS("src x/w must be multiple of 4 for rotated NV12\n");
> +		return -EINVAL;
> +	}
> +
> +	/* And round y here */
> +	plane_state->base.src.y1 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> +	plane_state->base.src.y2 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;

Why not just a simple

if (drm_rect_height(src) >> 16 % 4 != 0)
	return -EINVAL;

?

> +
> +	return 0;
> +}
> +
>  static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
>  {
>  	const struct drm_framebuffer *fb = plane_state->base.fb;
> @@ -3173,6 +3198,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
>  	 * the main surface setup depends on it.
>  	 */
>  	if (fb->format->format == DRM_FORMAT_NV12) {
> +		ret = skl_check_nv12_surface(crtc_state, plane_state);
> +		if (ret)
> +			return ret;
>  		ret = skl_check_nv12_aux_surface(plane_state);
>  		if (ret)
>  			return ret;

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx