public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Add BXT Sprite plane fractional scalings
Date: Thu, 26 Nov 2015 21:30:01 +0200	[thread overview]
Message-ID: <20151126193001.GJ4437@intel.com> (raw)
In-Reply-To: <20151126183342.GI4437@intel.com>

On Thu, Nov 26, 2015 at 08:33:42PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 26, 2015 at 11:49:43PM +0530, Nabendu Maiti wrote:
> > 
> > 
> > On 11/18/2015 06:49 PM, Ville Syrjälä wrote:
> > > On Wed, Nov 18, 2015 at 06:37:17PM +0530, Maiti, Nabendu Bikash wrote:
> > >>
> > >> On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
> > >>> On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
> > >>>> On older platforms scalers/cliping used to provide destination size an
> > >>>> exact multiple of src size.
> > >>>> Gen-9 and above support fractional ratio of dst/src so that source is
> > >>>> not manipulated to meet the exact multiple factor.
> > >>>>
> > >>>> Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
> > >>>> ---
> > >>>>    drivers/gpu/drm/i915/intel_sprite.c | 48 +++++++++++++++++++++----------------
> > >>>>    1 file changed, 28 insertions(+), 20 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > >>>> index 2b96f33..e8c17ae 100644
> > >>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> > >>>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > >>>> @@ -813,29 +813,37 @@ intel_check_sprite_plane(struct drm_plane *plane,
> > >>>>    	crtc_h = drm_rect_height(dst);
> > >>>>    
> > >>>>    	if (state->visible) {
> > >>>> -		/* check again in case clipping clamped the results */
> > >>>> -		hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> > >>>> -		if (hscale < 0) {
> > >>>> -			DRM_DEBUG_KMS("Horizontal scaling factor out of limits\n");
> > >>>> -			drm_rect_debug_print("src: ", src, true);
> > >>>> -			drm_rect_debug_print("dst: ", dst, false);
> > >>>> -
> > >>>> -			return hscale;
> > >>>> -		}
> > >>>>    
> > >>>> -		vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> > >>>> -		if (vscale < 0) {
> > >>>> -			DRM_DEBUG_KMS("Vertical scaling factor out of limits\n");
> > >>>> -			drm_rect_debug_print("src: ", src, true);
> > >>>> -			drm_rect_debug_print("dst: ", dst, false);
> > >>>> +		/* Gen 9 and above has fractional scaling support */
> > >>>> +		if (INTEL_INFO(plane->dev)->gen < 9) {
> > >>>>    
> > >>>> -			return vscale;
> > >>>> -		}
> > >>>> +			/* check again in case clipping clamped the results */
> > >>>> +			hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> > >>>> +			if (hscale < 0) {
> > >>>> +				DRM_DEBUG_KMS("Horizontal scaling factor out of limits\n");
> > >>>> +				drm_rect_debug_print("src: ", src, true);
> > >>>> +				drm_rect_debug_print("dst: ", dst, false);
> > >>>> +
> > >>>> +				return hscale;
> > >>>> +			}
> > >>>> +
> > >>>> +			vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> > >>>> +			if (vscale < 0) {
> > >>>> +				DRM_DEBUG_KMS("Vertical scaling factor out of limits\n");
> > >>>> +				drm_rect_debug_print("src: ", src, true);
> > >>>> +				drm_rect_debug_print("dst: ", dst, false);
> > >>>>    
> > >>>> -		/* 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));
> > >>>> +				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));
> > >>>> +		}
> > >>> NAK. This code just makes sure the actual scaling ratio matches what we
> > >>> calculated. As in there may have been some amount of rounding involved
> > >>> etc.
> > >>>
> > >>> The part you actually want to change is what comes after this where we
> > >>> throw away the fractional part of the coordinates. And then you need to
> > >>> change the actual hw programming so that we actually feed the sub-pixel
> > >>> coordinates to the hardware.
> > >> In line
> > >>
> > >> drm_rect_adjust_size(src,
> > >> +					     drm_rect_width(dst) * hscale - drm_rect_width(src),
> > >> +					     drm_rect_height(dst) * vscale - drm_rect_height(src));
> > >>
> > >> I think we throw away the fractional part,
> > > No, we don't.
> > It get changed for example src size 400x596   to destination 1055x700.
> > then  i.e. u32/int hscale = (src * 0x10000)/dst = 0x1900000/0x41f = 
> > 26214400/1055= 24847 (actually 24847.772511848)
> > so in next line it get modified .
> > 
> > drm_rect_adjust_size(src,
> > +					     drm_rect_width(dst) * hscale - drm_rect_width(src),
> > +					     drm_rect_height(dst) * vscale - drm_rect_height(src)); ,
> > 
> > Src width become 399, which is used for further calculation & commiting.
> 
> No, it becomes
> hscale = floor(400 * 2^16 / 1055) = 24847
> src width = 24847 * 1055 = 26213585
> src width / 2^16 ~= 399.9876
> 
> The fractional bits are thrown away later when somone does src width >>16.

Just to clarify a bit. I origianally wrote this stuff for nice hardware
which can handle sub-pixel coordinates and where you actually program
the scaling factor into the hardware. Doing the rect adjustment avoids
throwing away data from just the right/bottom edges of the image and
instead throws away a bit from each edge.

If the hardware doesn't operate like this (eg. doesn't do sub-pixel
coordinates at all) then I guess it might make sense to not do this. But
then we run into the question that what happens if the scaling ratio is
actually slightly over the max (since we truncate the result from
the src/dst computation it can happen). Without knowing the internals of
the hardware it's hard to say what it will do.

I guess what we could do is check the scaling ratio without the
truncation, and then we should be somewhat certain that things will
work. So eg,. something like this:

int drm_rect_check_hscale(const struct drm_rect *src,
			  const struct drm_rect *dst,
			  int min_hscale, int max_hscale)
{
	int src_w = drm_rect_width(src);
	int64_t dst_w = drm_rect_width(dst);

	if (src_w < min_hscale * dst_w ||
	    src_w > max_hscale * dst_w)
		return -ERANGE;

	return 0;
}

And then I guess we'd need to change the relaxed scaling calculations
too so that they do the scaling ratio comparison this same way.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-11-26 19:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 11:43 [PATCH] drm/i915: Add BXT Sprite plane fractional scalings Nabendu Maiti
2015-11-18 12:11 ` Ville Syrjälä
2015-11-18 13:07   ` Maiti, Nabendu Bikash
2015-11-18 13:19     ` Ville Syrjälä
2015-11-26 18:19       ` Nabendu Maiti
2015-11-26 18:33         ` Ville Syrjälä
2015-11-26 19:30           ` Ville Syrjälä [this message]
2015-12-07 18:15             ` Nabendu Maiti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151126193001.GJ4437@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=nabendu.bikash.maiti@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox