<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> <o:p> </o:p> <a name="_MailEndCompose"><o:p> </o:p></a> <a name="_____replyseparator"></a>> -----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 <<a href="mailto:maarten.lankhorst@linux.intel.com">maarten.lankhorst@linux.intel.com</a>> > > >> > > >> 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 > > >> <<a href="mailto:maarten.lankhorst@linux.intel.com">maarten.lankhorst@linux.intel.com</a>> > > >> Signed-off-by: Vidya Srinivas <<a href="mailto:vidya.srinivas@intel.com">vidya.srinivas@intel.com</a>> > > >> --- > > >> 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. <o:p> </o:p> Hi<o:p></o:p> <o:p> </o:p> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.<o:p></o:p> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.<o:p></o:p> <o:p> </o:p> As per experiments on APL and KBL, when we don’t keep them multiple of 4, we see fifo underruns.<o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> Vidya<o:p></o:p> <o:p> </o:p> > > -- > Ville Syrjälä > Intel </div> </body> </html>