From ee539e58c3bf39766c560d625f6e4158d419e64e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= Date: Mon, 8 Jun 2009 21:14:14 -0400 Subject: [PATCH] Fall back to fb pixmaps for backing glyph pictures GEM pads pixmaps to 512 byte stride and backs them with a kernel side buffer objects. We typically don't render out of glyph pictures, so we're incurring a lot of overhead per glyph by allocating a GEM pixmap per glyph. By looking at the usage hint, we can fall back to fbCreatePixmap for pixmaps backing glyph pictures, which gives us a nice tight malloced pixmap. The fast path for text rendering is compositing from the glyph cache pixmap to the destination, which shouldn't be significantly affected. Quick bit of testing: (firefox-20090601) xlib-rgba-before 384512.49: 1.01x xlib-rgba-after 389633.94: 1.00x The difference being within the margin of error for the benchmark. Signed-off-by: Eric Anholt Tested-by: Chris Wilson --- src/i830_exa.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/i830_exa.c b/src/i830_exa.c index d0ada02f..eb35014e 100644 --- a/src/i830_exa.c +++ b/src/i830_exa.c @@ -598,6 +598,9 @@ i830_uxa_create_pixmap (ScreenPtr screen, int w, int h, int depth, unsigned usag if (w > 32767 || h > 32767) return NullPixmap; + if (usage == CREATE_PIXMAP_USAGE_GLYPH_PICTURE) + return fbCreatePixmap (screen, w, h, depth, usage); + pixmap = fbCreatePixmap (screen, 0, 0, depth, usage); if (w && h)