Michel,
Sure. Firstly, Geode is not ATI and Intel graphics card:). I have a
RS690 board. As you said, the speed is nearly 700000/s.
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. 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. So for geode, it can not
be fully implemented using HW way. 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).
Right now, using the fully SW way(Do PictOpAdd one by one), I have put
the performance up 4 times. As before, it is 5500/s. So I think we should
accept this way right now.
Thanks,
Frank
-----Original Message-----
From: Michel Dänzer [mailto:[email protected]]
Sent: 2010年7月21日 15:18
To: Huang, FrankR
Cc: Alex Deucher; Mart Raudsepp; Torres, Rigo; Writer, Tim;
[email protected]; [email protected]; Cui, Hunk; Deucher,
Alexander
Subject: RE: Glyph rendering
On Mit, 2010-07-21 at 11:27 +0800, Huang, FrankR wrote:
>
> I am trying to use ARGB to play a trick to do the PICT_a8 add. From
> the debug, the memory space add value is right. But the final result
> is not correct.
It might be possible to pull this off if the hardware supports a
writemask for the ARGB destination.
> Then I wrote a function to do the PICT_a8 add operation( MAX(x+y,
> 255)), the result is right. And the performance has grown up to
> 23700/s. It is same as using "NoAccel" way:).
That still seems rather low though - radeon/intel/nouveau drivers easily
get beyond 10x that. I suspect you could also get much better still if
you can eliminate any software rendering and other GPU pipeline stalls.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
