| Message ID | 1524024493-23173-7-git-send-email-vidya.srinivas@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote: > From: Maarten Lankhorst <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 The patch looks good to me. Reviewed-by: Mika Kahola <mika.kahola@intel.com> > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Signed-off-by: Vidya Srinivas <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; > + } > + > + /* 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; > + } > + > + 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; > + > + return 0; > +} > + > static int skl_check_nv12_aux_surface(struct intel_plane_state > *plane_state) > { > const struct drm_framebuffer *fb = plane_state->base.fb; > @@ -3201,6 +3237,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; > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > b/drivers/gpu/drm/i915/intel_sprite.c > index 8b7947d..f9985fb 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane > *plane, > return vscale; > } > > - /* Make the source viewport size an exact multiple > of the scaling factors. */ > - drm_rect_adjust_size(src, > - drm_rect_width(dst) * hscale - > drm_rect_width(src), > - drm_rect_height(dst) * vscale - > drm_rect_height(src)); > + if (fb->format->format != DRM_FORMAT_NV12) { > + /* > + * Make the source viewport size > + * an exact multiple of the scaling factors > + */ > + drm_rect_adjust_size(src, > + (drm_rect_width(dst) * > hscale - > + drm_rect_width(src)), > + (drm_rect_height(dst) * > vscale - > + drm_rect_height(src))) > ; > + } > > drm_rect_rotate_inv(src, fb->width << 16, fb->height > << 16, > state->base.rotation);
On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: > From: Maarten Lankhorst <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> > Signed-off-by: Vidya Srinivas <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. > + > + /* 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. > + > + 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. > + > + return 0; > +} > + > static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state) > { > const struct drm_framebuffer *fb = plane_state->base.fb; > @@ -3201,6 +3237,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; > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > index 8b7947d..f9985fb 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane, > return vscale; > } > > - /* Make the source viewport size an exact multiple of the scaling factors. */ > - drm_rect_adjust_size(src, > - drm_rect_width(dst) * hscale - drm_rect_width(src), > - drm_rect_height(dst) * vscale - drm_rect_height(src)); > + if (fb->format->format != DRM_FORMAT_NV12) { > + /* > + * Make the source viewport size > + * an exact multiple of the scaling factors > + */ > + drm_rect_adjust_size(src, > + (drm_rect_width(dst) * hscale - > + drm_rect_width(src)), > + (drm_rect_height(dst) * vscale - > + drm_rect_height(src))); > + } > > drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, > state->base.rotation); > -- > 2.7.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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> >> >> 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> >> Signed-off-by: Vidya Srinivas <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. >> + >> + /* 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. >> + >> + 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. :)
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> > >> > >> 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> > >> Signed-off-by: Vidya Srinivas <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.
> -----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. As per experiments on APL and KBL, when we don't keep them multiple of 4, we see fifo underruns. Regards Vidya > > -- > Ville Syrjälä > Intel
> -----Original Message----- > From: Kahola, Mika > Sent: Wednesday, April 18, 2018 5:39 PM > To: 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, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote: > > From: Maarten Lankhorst <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 > The patch looks good to me. > > Reviewed-by: Mika Kahola <mika.kahola@intel.com> Thank you. Will add the RB in next push. Regards Vidya > > > > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Signed-off-by: Vidya Srinivas <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; > > + } > > + > > + /* 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; > > + } > > + > > + 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; > > + > > + return 0; > > +} > > + > > static int skl_check_nv12_aux_surface(struct intel_plane_state > > *plane_state) > > { > > const struct drm_framebuffer *fb = plane_state->base.fb; @@ - > 3201,6 > > +3237,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; > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > b/drivers/gpu/drm/i915/intel_sprite.c > > index 8b7947d..f9985fb 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane > > *plane, > > return vscale; > > } > > > > - /* Make the source viewport size an exact multiple > > of the scaling factors. */ > > - drm_rect_adjust_size(src, > > - drm_rect_width(dst) * hscale - > > drm_rect_width(src), > > - drm_rect_height(dst) * vscale - > > drm_rect_height(src)); > > + if (fb->format->format != DRM_FORMAT_NV12) { > > + /* > > + * Make the source viewport size > > + * an exact multiple of the scaling factors > > + */ > > + drm_rect_adjust_size(src, > > + (drm_rect_width(dst) * > > hscale - > > + drm_rect_width(src)), > > + (drm_rect_height(dst) * > > vscale - > > + drm_rect_height(src))) > > ; > > + } > > > > drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, > > state->base.rotation); > -- > Mika Kahola - Intel OTC
Op 18-04-18 om 20:35 schreef Ville Syrjälä: > 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> >>>> >>>> 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> >>>> Signed-off-by: Vidya Srinivas <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. Would we break anything if we disallow sub-pixel coordinates for i915 globally? It's not like we supported them before, but I'm not sure that change would break anything. >>>> + >>>> + /* 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. Yes, but it will always be smaller than the original rectangle, so rounding to 4 when the original set of coordinates were a multiple of 4 would never go outside the original boundary. > Also why are we trying to make everything a multiple of four? I don't > remember any hw restrictions like that. Well Vidya already replied, it sucks but it's what we have to live with for now. :(
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. > > > > As per experiments on APL and KBL, when we don't keep them multiple of 4, we see fifo underruns. > > > > Regards > > Vidya > > > > > > > > -- > > > Ville Syrjälä > > > Intel
On Thu, Apr 19, 2018 at 10:12:56AM +0200, Maarten Lankhorst wrote: > Op 18-04-18 om 20:35 schreef Ville Syrjälä: > > 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> > >>>> > >>>> 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> > >>>> Signed-off-by: Vidya Srinivas <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. > > Would we break anything if we disallow sub-pixel coordinates for i915 globally? It's not like we supported them before, > but I'm not sure that change would break anything. Not really I suppose. IIRC the hw did reintroduce partial sub-pixel coordinate support for NV12 specifically. I do wish they'd done it fully for all formats. > > >>>> + > >>>> + /* 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. > > Yes, but it will always be smaller than the original rectangle, so rounding to 4 when > the original set of coordinates were a multiple of 4 would never go outside the original > boundary. I was talking about the scaling factor increasing, and potentially exceeding the hardware maximum. > > > Also why are we trying to make everything a multiple of four? I don't > > remember any hw restrictions like that. > > Well Vidya already replied, it sucks but it's what we have to live with for now. :( That was just about the plane height. Nothing seems to require making everything a multiple of four.
Op 19-04-18 om 13:32 schreef Ville Syrjälä: > On Thu, Apr 19, 2018 at 10:12:56AM +0200, Maarten Lankhorst wrote: >> Op 18-04-18 om 20:35 schreef Ville Syrjälä: >>> 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> >>>>>> >>>>>> 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> >>>>>> Signed-off-by: Vidya Srinivas <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. >> Would we break anything if we disallow sub-pixel coordinates for i915 globally? It's not like we supported them before, >> but I'm not sure that change would break anything. > Not really I suppose. IIRC the hw did reintroduce partial sub-pixel > coordinate support for NV12 specifically. I do wish they'd done it > fully for all formats. > >>>>>> + >>>>>> + /* 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. >> Yes, but it will always be smaller than the original rectangle, so rounding to 4 when >> the original set of coordinates were a multiple of 4 would never go outside the original >> boundary. > I was talking about the scaling factor increasing, and potentially > exceeding the hardware maximum. > >>> Also why are we trying to make everything a multiple of four? I don't >>> remember any hw restrictions like that. >> Well Vidya already replied, it sucks but it's what we have to live with for now. :( > That was just about the plane height. Nothing seems to require making > everything a multiple of four. > This was to get rid of FIFO underruns, but the new solution appears to be not enable it on BXT. I can live with that. :)
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; + } + + /* 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; + } + + 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; + + return 0; +} + static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state) { const struct drm_framebuffer *fb = plane_state->base.fb; @@ -3201,6 +3237,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; diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 8b7947d..f9985fb 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane, return vscale; } - /* Make the source viewport size an exact multiple of the scaling factors. */ - drm_rect_adjust_size(src, - drm_rect_width(dst) * hscale - drm_rect_width(src), - drm_rect_height(dst) * vscale - drm_rect_height(src)); + if (fb->format->format != DRM_FORMAT_NV12) { + /* + * Make the source viewport size + * an exact multiple of the scaling factors + */ + drm_rect_adjust_size(src, + (drm_rect_width(dst) * hscale - + drm_rect_width(src)), + (drm_rect_height(dst) * vscale - + drm_rect_height(src))); + } drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, state->base.rotation);