Glyph rendering

[Michel Dänzer]

[ Fixed your quoting, please consider using a better e-mail client ]

On Mit, 2010-07-21 at 16:11 +0800, Huang, FrankR wrote: 
> 
> From: Michel Dänzer [mailto:michel at daenzer.net] 
> 
> > On Mit, 2010-07-21 at 15:30 +0800, Huang, FrankR wrote: 
> > > 
> > > 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.
> 
> 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. :(

Yes, that's what I meant.


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

Ahem.

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

I figured that, which means the driver is responsible for making sure
the GPU and CPU properly see each other's rendering results.


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