[Xorg-driver-geode] Glyph rendering

[Mart Raudsepp]

Hello,

On N, 2010-07-15 at 17:59 +0200, Michel Dänzer wrote:
> On Don, 2010-07-15 at 14:13 +0300, Mart Raudsepp wrote: 
> > On N, 2010-07-15 at 17:35 +0800, Huang, FrankR wrote:
> > > Jonathan,
> > > 
> > > 	That's Mart's findings. I am not sure if he got it from debug or from code.
> > > 	From my debug, only three rendering requests for "x11perf -aa10text" are met in lx_check_composite. That three requests are still:
> > > 	1)Op:PictOpAdd, Src:PICT_a8r8g8b8 Mask:0 Dest:PICT_a8
> > 
> > 
> > I got it from code and Michel. The source is just a pointer at the code
> > I was looking at, and I didn't track that all the way down to its
> > creation, as Michel said that source should commonly be PICT_a8 there.
> > 
> > The first checks destination is definitely PICT_a8 on first try.
> > 
> > The source to CheckComposite call comes from exaGlyphs second argument,
> > which seems to be the src PICTURE passed from CompositeGlyphs{8,16,32}.
> > This appears to be the 1x1 pixel with repeat set solid color...
> > Why would we try to PictOpAdd that solid color to a PICT_a8 glyph alpha
> > masks cache to decide if glyph mask copy to glyph cache is possible?
> > Later the PictOpAdd operation is done with buffer->mask as the source
> > instead..
> > 
> > Is my analysis correct and there's a bug like that in Xserver commit
> > 346e7152?
> 
> Yeah. :( Probably best just to revert that commit, given it was intended
> to help you guys but failed quite spectacularly at that...

Probably. Would probably take quite should reshuffling otherwise to work
as intended, as the buffer pointer is gotten much later on.


But this means we'll have to add Src:PICT_a8r8g8b8 Mask:0 Dest:PICT_a8
PictOpAdd acceleration support still at rather high priority to be fast
in existing out-the-door xorg-server-1.6/1.7/1.8 releases.


Frank: Src:PICT_a8 Mask:0 Dst:PICT_a8 PictOpAdd is higher priority to
get text working faster on any xorg-server, as that's a prerequisite
either way for fast text, but you need to get 346e7152 reverted in your
xserver to have any meaningful benchmark results to go alongside your
work. Of course for just acceleration code writing you can write your
own minimal test cases outside glyph rendering too, but it's probably
hard to display a8 destinations on screen without an additional step
with it used as a mask ;)

PICT_a8r8g8b8 source support in this situation can probably be added
later or at the same go, the code paths are probably quite the same,
just need to ignore RGB channels.

We can probably get OLPC XO-1 upcoming release xorg-server to be patched
with the revert of commit 346e7152 if it is beneficial for their speed.


> P.S. I asked for more information about where the format combination
> above was coming from last Monday...

Yeah, no problem. Latest mails and discussions triggered me to dig
deeper, once Frank said he doesn't see any a8 to a8 at all.
Many thanks for all your help so far.


Regards,
Mart Raudsepp