uxa: Enable SHM pixmaps

Now with streaming uploads and downloads for composite operations in
place, shared memory pixmaps are no longer that dire performance wise.
With careful use these can in fact be the most efficient means of
transfer between a wholly software renderer in the client and a backing
store. For instance, Chromium renders internally to an ARGB32 image
buffer and uses a shared pixmap to composite dirty regions into the
backing store. Thereby using the GPU to either perform the blit or the
format conversion. Enabling shared pixmaps, reduces our CPU overhead
whilst scrolling by a factor of 5 or so.

And this is achieved simply by deleting obsolete code!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 4b7142baa0b3bf6f38843d06aadc579d8624cefc)

Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>

1 files changed, 0 insertions, 8 deletions

diff --git a/uxa/uxa.c b/uxa/uxa.c
index a48c3e13..37546dc3 100644
--- a/uxa/uxa.c
+++ b/uxa/uxa.c
@@ -544,14 +544,6 @@ Bool uxa_driver_init(ScreenPtr screen, uxa_driver_t * uxa_driver)
 	}
 #endif
 
-#ifdef MITSHM
-	/* Re-register with the MI funcs, which don't allow shared pixmaps.
-	 * Shared pixmaps are almost always a performance loss for us, but this
-	 * still allows for SHM PutImage.
-	 */
-	ShmRegisterFuncs(screen, &uxa_shm_funcs);
-#endif
-
 	LogMessage(X_INFO,
 		   "UXA(%d): Driver registered support for the following"
 		   " operations:\n", screen->myNum);