Michel Dänzer <[email protected]> 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. -- [email protected]
pgpAFYX8D7Li0.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
