From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Srinivas, Vidya" Subject: Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12 Date: Thu, 19 Apr 2018 02:36:42 +0000 Message-ID: References: <1524024493-23173-1-git-send-email-vidya.srinivas@intel.com> <1524024493-23173-7-git-send-email-vidya.srinivas@intel.com> <20180418153256.GV17795@intel.com> <9be96a32-cffa-5517-3363-461e882380be@linux.intel.com> <20180418183556.GY17795@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0522037116==" Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 13FE16E063 for ; Thu, 19 Apr 2018 02:36:48 +0000 (UTC) In-Reply-To: <20180418183556.GY17795@intel.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: =?iso-8859-1?Q?Ville_Syrj=E4l=E4?= , Maarten Lankhorst Cc: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org --===============0522037116== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_F653A0A18852B74D88578FA2EB7094EAB686568ABGSMSX107garcor_" --_000_F653A0A18852B74D88578FA2EB7094EAB686568ABGSMSX107garcor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ville Syrj=E4l=E4 [mailto:ville.syrjala@linux.intel.com] > Sent: Thursday, April 19, 2018 12:06 AM > To: Maarten Lankhorst > Cc: Srinivas, Vidya ; 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=E4l=E4: > > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: > > >> From: Maarten Lankhorst > > > >> > > >> 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 > > >> > > > >> Signed-off-by: Vidya Srinivas > > > >> --- > > >> 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 *pl= ane_state) { > > >> + int crtc_x2 =3D plane_state->base.crtc_x + plane_st= ate->base.crtc_w; > > >> + int crtc_y2 =3D plane_state->base.crtc_y + > > >> +plane_state->base.crtc_h; > > >> + > > >> + if (((plane_state->base.src_x >> 16) % 4) !=3D 0 || > > >> + ((plane_state->base.src_y >> 16) % 4) !=3D 0 || > > >> + ((plane_state->base.src_w >> 16) % 4) !=3D 0 || > > >> + ((plane_state->base.src_h >> 16) % 4) !=3D 0) { > > >> + DRM_DEBUG_KMS("src coords must be m= ultiple 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 the= y > 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->p= ipe_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 =3D > > >> + DIV_ROUND_CLOSEST(plane_state->base= .src.x1, 1 << 18) << > 18; > > >> + plane_state->base.src.x2 =3D > > >> + DIV_ROUND_CLOSEST(plane_state->base= .src.x2, 1 << 18) << > 18; > > >> + plane_state->base.src.y1 =3D > > >> + DIV_ROUND_CLOSEST(plane_state->base= .src.y1, 1 << 18) << > 18; > > >> + plane_state->base.src.y2 =3D > > >> + 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 pr= ogrammed plane height to be a multiple of 4. As per experiments on APL and KBL, when we don't keep them multiple of 4, w= e see fifo underruns. Regards Vidya > > -- > Ville Syrj=E4l=E4 > Intel --_000_F653A0A18852B74D88578FA2EB7094EAB686568ABGSMSX107garcor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 =

> -----Ori= ginal Message-----

> From: Ville Syrj=E4l=E4 [mailto:ville.syrjal= a@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= =E4l=E4:

> > > On Wed, Apr 18, 2018 at 09:38:13AM= +0530, Vidya Srinivas wrote:

> > >> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com&= gt;

> > >>

> > >> We skip src trunction/adjustme= nts for

> > >> NV12 case and handle the sizes= directly.

> > >> Without this, pipe fifo underr= uns are seen on APL/KBL.

> > >>

> > >> v2: For NV12, making the src c= oordinates multiplier of 4

> > >>

> > >> v3: Moving all the src coords = handling code for NV12 to

> > >> skl_check_nv12_surface

> > >>

> > >> Signed-off-by: Maarten Lankhor= st

> > >> <maarten.lankhorst@linux.intel.com>

> > >> Signed-off-by: Vidya Srinivas = <vidya.srinivas@intel.com>

> > >> ---

> > >>  drivers/gpu/drm/i915/int= el_display.c | 39

> > >> ++++++= +++++++++++++++= +++++++++++++++=

> > >>  drivers/gpu/drm/i915/int= el_sprite.c  | 15 ++++++++++--= --

> > >>  2 files changed, 50 inse= rtions(+), 4 deletions(-)

> > >>

> > >> diff --git a/drivers/gpu/drm/i= 915/intel_display.c

> > >> b/drivers/gpu/drm/i915/intel_d= isplay.c

> > >> index 925402e..b8dbaca 100644<= /p>

> > >> --- a/drivers/gpu/drm/i915/int= el_display.c

> > >> +++ b/drivers/gpu/= drm/i915/intel_display.c

> > >> @@ -3118,6 +3118,42 @@ sta= tic int skl_check_main_surface(const

> struct intel_crtc_state *crtc_state,

> > >>  return 0;

> > >>  }

> > >>

> > >> +static int

> > >> +skl_check_nv12_surface(co= nst struct intel_crtc_state *crtc_state,

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;         struct intel_plane_state *= plane_state) {

> > >> +    &= nbsp;           int crtc_= x2 =3D plane_state->base.crtc_x + plane_state->base.crtc_w;

> > >> +    &= nbsp;           int crtc_= y2 =3D plane_state->base.crtc_y +

> > >> +plane_state->base.crtc= _h;

> > >> +

> > >> +    &= nbsp;           if (((pla= ne_state->base.src_x >> 16) % 4) !=3D 0 ||

> > >> +    &= nbsp;            &nb= sp;  ((plane_state->base.src_y >> 16) % 4) !=3D 0 ||

> > >> +    &= nbsp;            &nb= sp;  ((plane_state->base.src_w >> 16) % 4) !=3D 0 ||

> > >> +    &= nbsp;            &nb= sp;  ((plane_state->base.src_h >> 16) % 4) !=3D 0) {

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  DRM_DEBUG_KMS("src coords must be multiple of 4 for

> NV12\n");

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  return -EINVAL;

> > >> +    &= nbsp;           }

> > > I don't really see why we should c= heck these. The clipped

> > > coordinates are what matters.

> >

> > To propagate our limits to the userspac= e. 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 fo= r 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 limit= s from the start.

>

> But what about sub-pixel coordinates? You're= totally ignoring them here.

> We need to come up with some proper rules fo= r this stuff.

>

> >

> > >> +

> > >> +    &= nbsp;           /* Clippi= ng would cause a 1-3 pixel gap at the edge of the screen? */

> > >> +    &= nbsp;           if ((crtc= _x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %

> 4) ||

> > >> +    &= nbsp;            &nb= sp;  (crtc_y2 > crtc_state->pipe_src_h && crtc_state->= ;pipe_src_h % 4))

> {

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  DRM_DEBUG_KMS("It's not possible to clip %u,%u to

> %u,%u\n",

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            crtc_x2, cr= tc_y2,

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            crtc_state-= >pipe_src_w, crtc_state->pipe_src_h);

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  return -EINVAL;

> > >> +    &= nbsp;           }

> > > Why should we care? The current co= de already plays it fast and loose

> > > and allows the dst rectangle to sh= rink to accomodate the hw limits.

> > > If we want to change that we shoul= d change it universally.

> >

> > Unfortunately for the other formats we = already have an existing

> > userspace

> > (X.org) that doesn't perform any valida= tion. We can't change it for

> > that, but we can prevent future mistake= s.

>

> We should do it uniformly. Not per-format. T= hat will make the code

> unmaintainable real quick.

>

> >

> > >> +

> > >> +    &= nbsp;           plane_sta= te->base.src.x1 =3D

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) &= lt;<

> 18;

> > >> +    &= nbsp;           plane_sta= te->base.src.x2 =3D

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) &= lt;<

> 18;

> > >> +    &= nbsp;           plane_sta= te->base.src.y1 =3D

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) &= lt;<

> 18;

> > >> +    &= nbsp;           plane_sta= te->base.src.y2 =3D

> > >> +    &= nbsp;           &nbs= p;            &= nbsp;  DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) &= lt;<

> 18;

> > > Since this can now increase the si= ze of the source rectangle our

> > > scaling factor checks are no longe= r 100% valid. We might end up with

> > > a scaling factor that is too high.=

> > >

> > > I don't really like any of these &= quot;let's make NV12 behave special"

> > > tricks. We should make the code be= have the same way for all pixel

> > > formats instead of adding format s= pecific hacks.

> >

> > This is not nivalid because we restrict= the original src coordinates

> > to be a multiple of 4, you can only cli= p to something smaller, not to

> > something bigger. :)

>

> The clipped coordinates can be whatever than= ks 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<= /p>

 

As per WA1106, Display corruption/colo= r shift observed when using NV12 with 270 rotation or 90 rotation + hor= izontal flip.

WA: NV12 with 270 rotation or 90 rotation += horizontal flip requires the programmed plane height to be a multiple of 4= .

 

As per experiments on= APL and KBL, when we don’t keep them multiple of 4, we see fifo unde= rruns.

 

Regards

Vidya

 

>

> --

> Ville Syrj=E4l=E4

> Intel

--_000_F653A0A18852B74D88578FA2EB7094EAB686568ABGSMSX107garcor_-- --===============0522037116== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0522037116==--