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

[Eric Anholt]

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

> On Die, 2014-01-14 at 05:34 -0800, Keith Packard 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.
>
> 3) Given there is no point in sharing storage between CPU and GPU, keep
> them formatted 1bpp for the CPU and convert them to >1bpp for the GPU
> (and back to 1bpp for CPU readback).

One of keithp's assumptions has been that you have
reasonable-performance access to the texture memory for doing fallbacks.
It's how intel's uxa/glamor code manages decent performance with glamor
without running into some of the problems that radeon has faced (Like,
wow, diagonal lines.  That was amazingly bad).

I'd like to see glamor do better at rendering without fallbacks, and I
think ajax is also interested in pushing on that front.  It's certainly
not there yet, though, so you need fallbacks and they need to be less
awful if we want glamor to compare to native acceleration within this
year.  There are a couple of GL extensions related to this, such as
GL_INTEL_map_texture (which does't solve telling you how the texture
data is laid out in memory, plus has some very divergent mapping behavor
to the GL_ARB_mbr/GL_ARB_vbo-related MapTextureImage hook we have in
Mesa right now), or EGL_KHR_lock_surface3 (why EGL?  I want to map GL
textures, not EGL crap).  I think the right answer is to define a spec
that basically gives you Mesa's MapTextureImage hook, with format
definitions.

If you assume native mapping of texture buffers for fallbacks, then
having the X Server be able to operate directly on those textures makes
sense.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140115/ec8df812/attachment.pgp>