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

[Marek Olšák]

Even though GL has no support for 1bpp textures, they can be supported
indirectly. You can do the 1bpp <-> 8bpp conversion on the GPU using a
simple fragment shader. All you need is GL 3.0.

Same for A8. You can do the swizzling in the fragment shader for GLES,
but I'm not sure why we care about it. GL is superior to it and
eventually we would like to use GL_ARB_buffer_storage for vertex
uploads in glamor, which isn't available for GLES.

Marek

On Tue, Jan 14, 2014 at 2:34 PM, Keith Packard <keithp at keithp.com> wrote:
> 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
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel