Glyph rendering
Michel Dänzer
michel at daenzer.net
Wed Jul 21 01:24:13 PDT 2010
[ 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
More information about the xorg-devel
mailing list