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

[Michel Dänzer]

On Mit, 2014-01-15 at 01:27 -0800, Eric Anholt wrote:
> 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.

What's the plan for dealing with GPU tiling in this scheme? Disabling
tiling for all textures which could be hit by software fallbacks seems
like a bad plan for GPU performance.


> 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.

But why are you putting so much effort into trying to share storage
between GPU and CPU for bitmaps, given that SNA has apparently proved
such sharing is not beneficial overall even on Intel GPUs?

It seems more useful to spend effort on maintaining separate persistent
CPU storage for software fallbacks, which has proven effective in EXA
and SNA.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140116/86f42f08/attachment.pgp>