Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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 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 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

* 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