[Intel-gfx] [PATCH] Fall back to fb pixmaps for backing glyph pictures

[Chris Wilson]

On Mon, 2009-06-08 at 21:14 -0400, Kristian Hoegsberg wrote:
> 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.

cat /sys/kernel/debug/dri/0/gem_objects (at an arbitrary point during
the second iteration):-
before:
  4522 objects
  275714048 object bytes
  4 pinned
  3829760 pin bytes
  231075840 gtt bytes
  260308992 gtt total

after:
  249 objects
  311947264 object bytes
  4 pinned
  3829760 pin bytes
  20606976 gtt bytes
  260308992 gtt total

Tested-by: Chris Wilson <chris at chris-wilson.co.uk>