uxa: Rearrange checking and preparing of composite textures.

  x11perf regression caused by 2D driver
  https://bugs.freedesktop.org/show_bug.cgi?id=28047

caused by

  commit a7b800513fcc94e063dfd68d2f63b6bab7fae47d
  uxa: Extract sub-region from in-memory buffers.

The issue is that as we extract the region prior to checking whether the
composite can in fact be accelerated, we perform expensive surplus
operations. This is particularly noticeable for ComponentAlpha text,
such as rgb10text. The solution here is to rearrange the
check_composite() prior to acquiring the sources, and only extracting
the subregion if the render path can not actually handle the texture.

Performance (on PineView):
a7b800513^: aa=68600 glyphs/s, rgb=29900 glyphs/s
a7b800513: aa=65700 glyphs/s, rgb=13200 glyphs/s
now: aa=66800 glyph/s, rgb=28800 glyphs/s

The residual lossage seems to be from the extra function call and
dixPrivate lookups. Hmm. More warning is the extremely low performance,
however the results are consistent so the improvement looks real...

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

1 files changed, 13 insertions, 0 deletions

diff --git a/uxa/uxa.h b/uxa/uxa.h
index c7e5566a..32a86a96 100644
--- a/uxa/uxa.h
+++ b/uxa/uxa.h
@@ -252,6 +252,19 @@ typedef struct _UxaDriver {
 				PicturePtr pDstPicture);
 
 	/**
+	 * check_composite_texture() checks to see if a source to the composite
+	 * operation can be used without midification.
+	 *
+	 * @param pScreen Screen
+	 * @param pPicture Picture
+	 *
+	 * The check_composite_texture() call is recommended if prepare_composite() is
+	 * implemented, but is not required.
+	 */
+	Bool(*check_composite_texture) (ScreenPtr pScreen,
+					PicturePtr pPicture);
+
+	/**
 	 * prepare_composite() sets up the driver for doing a composite
 	 * operation described in the Render extension protocol spec.
 	 *