Glyph rendering

[Huang, FrankR]

-----Original Message-----
From: Michel Dänzer [mailto:michel at daenzer.net] 
Sent: 2010年7月21日 15:56
To: Huang, FrankR
Cc: Mart Raudsepp; Deucher, Alexander; Torres, Rigo; Writer, Tim; xorg-devel at lists.x.org; xorg-driver-geode at lists.x.org; Cui, Hunk
Subject: RE: Glyph rendering

On Mit, 2010-07-21 at 15:30 +0800, Huang, FrankR wrote: 
> 
> I have tested if it using PICT_a8r8g8b8 trick when it is fully
> implemented in HW(althought the result is wrong). The speed(may be is
> maximum) is nearly 100000/s.

That sounds better.


> But as you known, for the PICT_a8r8g8b8 method, the width and height
> of source sometimes can not be divied by 4(such as 5...), so the
> remaining pixel PictOpAdd should be done by SW code.

The height doesn't matter, and if there's a writemask it should be
possible to use that to mask out source/destination pixels that don't
align to an ARGB pixel.
[Frank] Yes. My description is not accurate, we only care width for this condition. Do you mean the writemask implemented in HW? From what I found, it is not in geode GP. :(


> For the mixed way(HW+SW as I described above), the speed can be
> 50000/s, unfortunely the result still is not correct(seems correct by
> debugging, I'm still checking it).

Sounds like maybe you're not properly synchronizing between GPU and CPU
access.
[Frank] Michael, maybe you misunderstand. The "SW" I mean is that our driver still use a formula to do the "+" operation in video memory instead of fallback to server handling(may be you means this). We don't fallback anymore.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer