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

[Zhigang Gong]

> -----Original Message-----
> From: xorg-devel-bounces at lists.x.org
[mailto:xorg-devel-bounces at lists.x.org]
> On Behalf Of Keith Packard
> Sent: Thursday, January 16, 2014 1:43 AM
> To: Eric Anholt; Michel Dänzer
> Cc: xorg-devel at lists.freedesktop.org
> Subject: Re: [PATCH 0/4] fb support for 8bpp bitmaps
> 
> Eric Anholt <eric at anholt.net> writes:
> 
> > One of keithp's assumptions has been that you have
> > reasonable-performance access to the texture memory for doing fallbacks.
> 
> It's actually a bit more subtle than that; what I want is to ensure that
when we
> switch to Glamor, we don't have any performance cliffs on existing
systems.
> The easiest way to ensure that is to make sure we can fall back to the
existing
> code without any performance penalty.
I agree with this point. Current glamor will treat those pixmaps who have a
valid
drm buffer as a special type of pixmap which could be pass back to the DDX
layer
driver to do the rendering. Then for this type of pixmap, when hit fallback,
we don't
handle the fallback within glamor which is extreme slow currently. Instead,
we just
simply return a false to the DDX driver, and the DDX will take care of it.

At the time I implemented the above logic the KHR_gl_texture_2D_image
extension was
not ready, only a small set of pixmaps have a valid drm buffer attached, so
the fallback is
still painful sometimes. I think we can get a valid drm buffer for every
texture on demand
by using the KHR_gl_texture_2D_image extension now. Ideally, we may avoid
any single
fallback within glamor.

> 
> For systems which currently depend for performance on using the CPU for
> some rendering operations, that means continuing to use those same paths
> until we create replacement code that offers comparable performance.
> 
> Ideally, we'll eventually write code which makes all core operations
faster with
> the GPU than with the CPU.
> 
> > 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.
> 
> Ideally, fallback performance under Glamor will match fallback performance
> under UXA. Then, we can replace fallbacks one at a time with even faster
code
> and keep everyone happy with the switch.
> 
> --
> keith.packard at intel.com