| Message ID | 6142ae0b-a9da-f553-2726-632d44d83168@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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;
Op 19-04-18 om 13:50 schreef Ville Syrjälä: > 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; > So lets do that, but we have to fix the rounding errors in i915 to make it useful: upscaling 16x16 to 2560x1440: (kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "SRC_W" to 0x100000/1048576 (kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "SRC_H" to 0x100000/1048576 (kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_X" to 0x0/0 (kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_Y" to 0x0/0 (kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_W" to 0xa00/2560 (kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_H" to 0x5a0/1440 [ 290.766555] [drm:drm_ioctl [drm]] pid=1172, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC ... [ 290.767276] [drm:skl_update_scaler [i915]] NV12: src dimensions not met: 15 < 16 [ 290.767284] [drm:drm_atomic_helper_check_planes [drm_kms_helper]] [PLANE:33:plane 2A] atomic driver check failed [ 290.767422] [drm:drm_ioctl [drm]] pid=1172, ret = -22 If we want to go with that patch, I'll commit it but let the tests fail since rounding is not a NV12 specific error. ~Maarten
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; + + /* 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; + + 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;