* Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling [not found] <20200206201204.31704-1-ville.syrjala@linux.intel.com> @ 2020-09-11 18:03 ` Jani Nikula 2020-09-14 13:48 ` Ville Syrjälä [not found] ` <20200206201204.31704-2-ville.syrjala@linux.intel.com> 1 sibling, 1 reply; 5+ messages in thread From: Jani Nikula @ 2020-09-11 18:03 UTC (permalink / raw) To: Ville Syrjala, intel-gfx On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Even if we're not doing downscaling we should account for > some of the extra dotclock limitations for g4x+ sprites. In > particular we must never exceed the 90% rule, and with RGB > that limits actually drops to 80%. > > So instead of bailing out when upscaling let's clamp the > scaling factor appropriately and go through the rest of > calculation normally. By luck we already did the full > calculations for the 1:1 case. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c > index 7abeefe8dce5..6e2e22d9bbaa 100644 > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > @@ -1611,8 +1611,7 @@ static int g4x_sprite_min_cdclk(const struct intel_crtc_state *crtc_state, > hscale = drm_rect_calc_hscale(&plane_state->uapi.src, > &plane_state->uapi.dst, > 0, INT_MAX); > - if (hscale < 0x10000) > - return pixel_rate; > + hscale = max(hscale, 0x10000u); It bugs me that drm_rect seems to be used for both integer and 16.16 fixed point and whatnot. It also gives me an uneasy feeling that hscale is uint while drm_rect_calc_hscale() may return -ERANGE... but I guess shouldn't happen. All in all, Reviewed-by: Jani Nikula <jani.nikula@intel.com> > > /* Decimation steps at 2x,4x,8x,16x */ > decimate = ilog2(hscale >> 16); -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling 2020-09-11 18:03 ` [Intel-gfx] [PATCH 1/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling Jani Nikula @ 2020-09-14 13:48 ` Ville Syrjälä 0 siblings, 0 replies; 5+ messages in thread From: Ville Syrjälä @ 2020-09-14 13:48 UTC (permalink / raw) To: Jani Nikula; +Cc: intel-gfx On Fri, Sep 11, 2020 at 09:03:36PM +0300, Jani Nikula wrote: > On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Even if we're not doing downscaling we should account for > > some of the extra dotclock limitations for g4x+ sprites. In > > particular we must never exceed the 90% rule, and with RGB > > that limits actually drops to 80%. > > > > So instead of bailing out when upscaling let's clamp the > > scaling factor appropriately and go through the rest of > > calculation normally. By luck we already did the full > > calculations for the 1:1 case. > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c > > index 7abeefe8dce5..6e2e22d9bbaa 100644 > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > > @@ -1611,8 +1611,7 @@ static int g4x_sprite_min_cdclk(const struct intel_crtc_state *crtc_state, > > hscale = drm_rect_calc_hscale(&plane_state->uapi.src, > > &plane_state->uapi.dst, > > 0, INT_MAX); > > - if (hscale < 0x10000) > > - return pixel_rate; > > + hscale = max(hscale, 0x10000u); > > It bugs me that drm_rect seems to be used for both integer and 16.16 > fixed point and whatnot. In theory it can use any arbitrary precision. There are a few functions which do assume .0 or .16 though. > > It also gives me an uneasy feeling that hscale is uint while > drm_rect_calc_hscale() may return -ERANGE... but I guess shouldn't > happen. Yeah, should not happen since we've already done this same calculation (+check for <0) earlier. I've occasionally pondered about stashing the h/vscale from that first check into the plane state so we wouldn't have to redo it here. But I never found sufficient motivation to actually do it. > > All in all, > > Reviewed-by: Jani Nikula <jani.nikula@intel.com> Ta. > > > > > > /* Decimation steps at 2x,4x,8x,16x */ > > decimate = ilog2(hscale >> 16); > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20200206201204.31704-2-ville.syrjala@linux.intel.com>]
* Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check [not found] ` <20200206201204.31704-2-ville.syrjala@linux.intel.com> @ 2020-09-11 18:13 ` Jani Nikula 2020-09-14 13:44 ` Ville Syrjälä 0 siblings, 1 reply; 5+ messages in thread From: Jani Nikula @ 2020-09-11 18:13 UTC (permalink / raw) To: Ville Syrjala, intel-gfx On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > g4x+ sprites have an extra cdclk limitation listed for RGB formats. > For some random reason I chose to use cpp>=4 as the check for that. > While that does actually work let's deobfuscate it by checking > for !is_yuv instead. I suspect is_yuv didn't exist way back when > I originally write the code. Mmh, there are formats with cpp >= 4 && is_yuv == true making this look like a functional change... but I presume those are not relevant and/or this change is the right thing to do anyway. Acked-by: Jani Nikula <jani.nikula@intel.com> > > Also drop the duplicate comment. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/display/intel_sprite.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c > index 6e2e22d9bbaa..f95fe2c99468 100644 > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > @@ -1624,8 +1624,8 @@ static int g4x_sprite_min_cdclk(const struct intel_crtc_state *crtc_state, > limit -= decimate; > > /* -10% for RGB */ > - if (fb->format->cpp[0] >= 4) > - limit--; /* -10% for RGB */ > + if (!fb->format->is_yuv) > + limit--; > > /* > * We should also do -10% if sprite scaling is enabled -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check 2020-09-11 18:13 ` [Intel-gfx] [PATCH 2/2] drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check Jani Nikula @ 2020-09-14 13:44 ` Ville Syrjälä 2020-09-14 15:20 ` Jani Nikula 0 siblings, 1 reply; 5+ messages in thread From: Ville Syrjälä @ 2020-09-14 13:44 UTC (permalink / raw) To: Jani Nikula; +Cc: intel-gfx On Fri, Sep 11, 2020 at 09:13:18PM +0300, Jani Nikula wrote: > On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > g4x+ sprites have an extra cdclk limitation listed for RGB formats. > > For some random reason I chose to use cpp>=4 as the check for that. > > While that does actually work let's deobfuscate it by checking > > for !is_yuv instead. I suspect is_yuv didn't exist way back when > > I originally write the code. > > Mmh, there are formats with cpp >= 4 && is_yuv == true making this look > like a functional change... but I presume those are not relevant and/or > this change is the right thing to do anyway. This only applies to g4x/ilk/snb which only support YUYV/etc. (cpp==2), and 32/64bpp RGB (cpp==4/8). > > Acked-by: Jani Nikula <jani.nikula@intel.com> > > > > > Also drop the duplicate comment. > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > drivers/gpu/drm/i915/display/intel_sprite.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c > > index 6e2e22d9bbaa..f95fe2c99468 100644 > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > > @@ -1624,8 +1624,8 @@ static int g4x_sprite_min_cdclk(const struct intel_crtc_state *crtc_state, > > limit -= decimate; > > > > /* -10% for RGB */ > > - if (fb->format->cpp[0] >= 4) > > - limit--; /* -10% for RGB */ > > + if (!fb->format->is_yuv) > > + limit--; > > > > /* > > * We should also do -10% if sprite scaling is enabled > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check 2020-09-14 13:44 ` Ville Syrjälä @ 2020-09-14 15:20 ` Jani Nikula 0 siblings, 0 replies; 5+ messages in thread From: Jani Nikula @ 2020-09-14 15:20 UTC (permalink / raw) To: Ville Syrjälä; +Cc: intel-gfx On Mon, 14 Sep 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Fri, Sep 11, 2020 at 09:13:18PM +0300, Jani Nikula wrote: >> On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com> >> > >> > g4x+ sprites have an extra cdclk limitation listed for RGB formats. >> > For some random reason I chose to use cpp>=4 as the check for that. >> > While that does actually work let's deobfuscate it by checking >> > for !is_yuv instead. I suspect is_yuv didn't exist way back when >> > I originally write the code. >> >> Mmh, there are formats with cpp >= 4 && is_yuv == true making this look >> like a functional change... but I presume those are not relevant and/or >> this change is the right thing to do anyway. > > This only applies to g4x/ilk/snb which only support > YUYV/etc. (cpp==2), and 32/64bpp RGB (cpp==4/8). Ack. > >> >> Acked-by: Jani Nikula <jani.nikula@intel.com> >> >> > >> > Also drop the duplicate comment. >> > >> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> >> > --- >> > drivers/gpu/drm/i915/display/intel_sprite.c | 4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c >> > index 6e2e22d9bbaa..f95fe2c99468 100644 >> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c >> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c >> > @@ -1624,8 +1624,8 @@ static int g4x_sprite_min_cdclk(const struct intel_crtc_state *crtc_state, >> > limit -= decimate; >> > >> > /* -10% for RGB */ >> > - if (fb->format->cpp[0] >= 4) >> > - limit--; /* -10% for RGB */ >> > + if (!fb->format->is_yuv) >> > + limit--; >> > >> > /* >> > * We should also do -10% if sprite scaling is enabled >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-09-14 15:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20200206201204.31704-1-ville.syrjala@linux.intel.com>
2020-09-11 18:03 ` [Intel-gfx] [PATCH 1/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling Jani Nikula
2020-09-14 13:48 ` Ville Syrjälä
[not found] ` <20200206201204.31704-2-ville.syrjala@linux.intel.com>
2020-09-11 18:13 ` [Intel-gfx] [PATCH 2/2] drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check Jani Nikula
2020-09-14 13:44 ` Ville Syrjälä
2020-09-14 15:20 ` Jani Nikula
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox