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 <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>

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)