[PATCH 0/4] fb support for 8bpp bitmaps

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> Didn't SNA prove though that sharing the same pixel storage for GPU and
> CPU doesn't give the overall best performance even with Intel GPUs? It
> certainly doesn't with most other GPUs.

Yes, and strangely enough, this change is designed to *help* with that
transition. We want to switch to a pure hardware accelerated design, but
current hardware can't deal with 1bpp surfaces. That leaves us with two
choices for depth 1 objects:

 1) Never draw them with the GPU and leave them formatted 1bpp.

 2) Always draw them with the GPU and format them 8bpp.

Choice 1) is where we are today and means that we cannot ever migrate to
a pure GPU solution, leaving us migrating depth-1 pixmaps forever.

Choice 2) is where we want to go, but one step along the way is to get
our current mixed CPU/GPU acceleration code running with 8bpp bitmaps,
and that means getting the CPU side working with 8bpp bitmaps. And,
we'll still need to deal with 1bpp images, so there will always be CPU
fallbacks for those cases; if you can mmap the GPU surface, we can
continue to use the existing fb image code for that.

Actually, given that GLES doesn't support A8 surfaces, it's probable
that we'll want to add 32bpp bitmap support as well. That should be a
simple matter of adding 32bpp support in the same places as I added 8bpp
support in this patch series. I'll go ahead and restructure the
interface to offer arbitrary bpp for bitmaps and have the driver request
the desired one, checking to make sure that's actually supported by the
fb code.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140114/03db5a8c/attachment.pgp>