[Xorg-driver-geode] Glyph rendering

[Huang, FrankR]

-----Original Message-----
From: Mart Raudsepp [mailto:leio at gentoo.org] 
Sent: 2010?7?14? 19:18
To: Huang, FrankR
Cc: Jonathan Morton; xorg-driver-geode at lists.x.org; michel at daenzer.net
Subject: Re: [Xorg-driver-geode] Glyph rendering

On E, 2010-07-12 at 18:06 +0800, Huang, FrankR wrote:
> Jonathan,
> 
> 	Our driver is in low performance in glyph rendering.
> 	Based on the debug and discussion with Michel, There are three
> operation:
> 	1)Op:PictOpAdd, Src:PICT_a8r8g8b8 Mask:0 Dest:PICT_a8
> 	2)Op:PictOpAdd, Src:PICT_a8 Mask:0 Dest:PICT_a8r8g8b8
> 	3)Op:PictOpOver, Src:PICT_a8r8g8b8 Mask:PICT_a8r8g8b8
> Dst:PICT_r5g6b5
> 	Right now, the geode driver fallback all. If we want to
> accelerate, How do handle these conditions?

Hello,

After some exa_glyphs.c code reading and discussion with Michel on IRC,
we should see this case happen as well:

Op:PictOpAdd, Src:PICT_a8 Mask:0 Dest:PICT_a8
[Frank]: I have not debug this point. The three operations are what I get for all.

which we would fallback due to:

/* XXX - I don't understand PICT_a8 enough - so I'm punting */
if (pSrc->format == PICT_a8 || pDst->format == PICT_a8)
	return FALSE;

and we should get this accelerated to have some hope of making text go
faster than pure software.
Also all other composite operations done in the glyph code, but I think
we already have all the rest accelerated, but only after this PictOpAdd
to a8 doesn't fallback anymore (as if it fallbacks, the formats used in
next steps change).
[Frank]Absolutely we need to open this judge and do the PICT_a8(src, dest) acceleration.


Then the glyph masks will be kept in PICT_a8 format, instead of
PICT_a8r8g8b8 and the actual rendering of glyphs we'll then be able to
accelerate as well in case of no subpixel hinting cases - per my own
educated guess the actual rendering is then: source 1x1 pixel of
appropriate text color with repeat set, mask a portion of that A8 glyph
cache or directly without cache involved, and destination as PICT_r5g6b5
or PICT_r8g8b8 depending on the screen output depth.
[Frank]Correct.

If we fallback this a8 source and destination PictOpAdd, exaGlyphs will
convert it to a8r8g8b8 and then we can't accelerate that either due to
PICT_a8r8g8b8 being passed as masks in later operation.

Something probably was possible to accelerate though, as otherwise I'd
expect it to be as fast as pure software...

But the PictOpAdd operation fallbacks if source is PICT_a8, and
PictOpOver operation fallbacks if mask is PICT_a8r8g8b8... weird.

Anyway, to make glyph rendering go faster than pure software, we need to
make PictOpAdd to a8 destinations accelerated. Possibly PictOpSrc as
well, but that might be converted to a copy before it reaches the driver
per Michel, so would need verification.
[Frank] Nobody give me a explicit signal it is as that.

For PictOpAdd to a8 destination, if source has RGB components, they
should be just dropped. But the common case should be that source is A8
as well. In which case per Michel:

<MrCooper> note that you should be able to treat a8 the same as a8r8g8b8
for PictOpAdd, so long as you make sure the pitch is a multiple of 4
bytes
<MrCooper> hmm, and the width as well, which is trickier

(basically treating it as a PictOpAdd of a8r8g8b8 source to a8r8g8b8
source with pitch and width being a multiple of 4, as it shouldn't
matter with PictOpAdd if it's a alpha channel or some color channel)


But maybe we can support A8 sources and destinations for most operations
in general in hardware? Seems like Jordan just never got to
investigating A8 sources and destinations, while working on Geode, to
try to accelerate them, judging by the comment above the fallback.

---

Ideally in the long run we'd make a8r8g8b8 masks accelerated as well, at
least if componentAlpha is FALSE, as then we can just drop RGB part and
do our a8 acceleration.
[Frank]If we only care alpha value of ARGB mask, we can do that acceleration.

componentAlpha is TRUE there in case of subpixel smoothing (hinting),
which some users desire to use in case of LCD screens. So in the even
longer future we could try accelerating those as well. Meanwhile users
will need to accept that if they want text go fast, they should turn off
subpixel smoothing. http://en.wikipedia.org/wiki/Subpixel_rendering



Regards,
Mart Raudsepp