From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagar Arun Kamble Subject: Re: [Intel-gfx] [PATCH v5 11/11] drm/i915: Calling rotate and inverse rotate transformations after clipping Date: Tue, 11 Feb 2014 23:06:25 +0530 Message-ID: <1392140185.28501.29.camel@sagar-desktop> References: <1392017478-4945-1-git-send-email-sagar.a.kamble@intel.com> <1392017478-4945-12-git-send-email-sagar.a.kamble@intel.com> <20140210133257.GK3891@intel.com> <1392118351.28501.21.camel@sagar-desktop> <20140211145615.GT3891@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140211145615.GT3891@intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org, David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, 2014-02-11 at 16:56 +0200, Ville Syrj=C3=A4l=C3=A4 wrote: > On Tue, Feb 11, 2014 at 05:02:31PM +0530, Sagar Arun Kamble wrote: > > On Mon, 2014-02-10 at 15:32 +0200, Ville Syrj=C3=A4l=C3=A4 wrote: > > > On Mon, Feb 10, 2014 at 01:01:18PM +0530, sagar.a.kamble@intel.co= m wrote: > > > > From: Sagar Kamble > > > >=20 > > > > With clipped sprites these transformations are not working. the= se > > > > functions transform complete sprite irrespective of clipping pr= esent. > > > > This leads to invisible portion of sprite show up when rotate 1= 80 if > > > > it was out of visible area before. > > > >=20 > > > > v4: Moved rotate transform for source rectangle after clipping. > > > > Added rotate and inverse rotate transform for destination rect. > > >=20 > > > Still NAK. > > >=20 > > > I just pushed rotation support to my glplane test app [1], and wi= th > > > with that my rotated clipping code works exactly as intended. > > >=20 > > > [1] git://gitorious.org/vsyrjala/glplane.git > > I tried this app. I think I am considering 180 degree rotation of > > clipped sprite plane differently. I have captured output with these > > rotate transforms moved before(clip-rotated) and after(rotate-clipp= ed) > > clipping code. > >=20 > > Which is valid? Rotating entire sprite and then clipping or Rotatin= g > > clipped portion? > >=20 > > Reference and Rotated output is attached FYI. > >=20 > > If rotating entire sprite is correct then this patch 11/11 is not n= eeded > > and can be abandoned. >=20 > The way I think of these things is roughly this: >=20 > You have the user specified source rectangle, where the coordinates s= pecify > the viewport into the framebuffer. This coordinate space is oriented = the > same was as the framebuffer itself, ie. the first pixel of the > framebuffer is at coordinates 0,0. So plane rotation doesn't affect t= his > at all. >=20 > Then you have the user specified destination/crtc rectangle, where th= e > coordinates specify the position of the plane within the crtc coordin= ate > space. So the first visible pixel the pipe will push out is at > coordinates 0,0. So again plane rotation doesn't affect this. >=20 > Then you have the rotation which simply specifies the transformation = to > be applied to the pixels when they "move" from the source rectangle t= o > the destination rectangle. So w/ 0 degree rotation the pixel at > src_x,src_y in the framebuffer will appear at position crtc_x,crtc_y > on the crtc output. With 180 degree rotation the pixel at src_x,src_y > will appear at crtc_x+crtc_w-1,crtc_y+crtc_h-1. >=20 > As clipping happens in the crtc coordinate space, we need to orient > the source coordindates the same way to get the correct clipping resu= lt. > So for example with 0 degrees rotation clipping the left side of the > destination rectangle must result in clipping the left side of the so= urce > rectangle as well. And with 180 degree rotation clipping the destinat= ion > rectangle on the left side must result in clipping the source rectang= le > on the right side. Left and right in each case referring to the origi= nal > unrotate coordinates. >=20 > So let's say we have the following situation w/ 180 degree rotation. > The letters inside the rects represented specific named pixels, > the FB rectangle represents the FB as specified by addfb2 ioctl, > the CRTC rectangle represents the pipe output (0,0 -> PIPESRC.w,h): >=20 > FB: CRTC: > 0,0 ___________ 0.0 __________ > | abcd | | | > | efgh | | | > |_________| |hgfe | > |dcba_____| > unclipped coordinates specified by user: > src_x=3D2,src_y=3D0 crtc_x=3D0,crtc_y=3D2 > src_w=3D4.src_h=3D2 crtc_w=3D4,crtc_h=3D2 >=20 > clipped coordinates: > src_x=3D2,src_y=3D0 crtc_x=3D0,crtc_y=3D2 > src_w=3D4.src_h=3D2 crtc_w=3D4,crtc_h=3D2 >=20 >=20 > Then the user moves the sprite one pixel to the left resulting on som= e > clipping (the X pixels). Note that the unclipped source coordinates d= o > not change here at all, in fact crtc_x is the only thing changed by t= he > user: >=20 > FB: CRTC: > 0,0 ___________ 0.0 __________ > | abcX | | | > | efgX | | | > |_________| Xgfe | > Xcba______| > unclipped coordinates specified by user: > src_x=3D2,src_y=3D0 crtc_x=3D-1,crtc_y=3D2 > src_w=3D4.src_h=3D2 crtc_w=3D 4,crtc_h=3D2 >=20 > clipped coordinates: > src_x=3D2,src_y=3D0 crtc_x=3D0,crtc_y=3D2 > src_w=3D3.src_h=3D2 crtc_w=3D3,crtc_h=3D2 >=20 Understood this now. Thank you Ville for providing this elaborate graphical view of the rotation cases. -Sagar