Christophe,
Just as Mart mentioned, because our driver HW rendering still has some
bugs need to fixed. We are focusing on this now. After the current patches are
reviewed and committed, we will turn to performance thing. I talked this with
Mart few days ago, I think he has provided me the performance comparision on
the SW and HW rendering using the test case. I have seen the result. Let's
foucs on the HW rendering performance thing. See our update in the mail list
and give your comments.
Thanks,
Frank
-----Original Message-----
From: xorg-driver-geode-bounces+frankr.huang=amd....@lists.x.org
[mailto:xorg-driver-geode-bounces+frankr.huang=amd....@lists.x.org] On Behalf
Of Mart Raudsepp
Sent: 2010?7?6? 22:15
To: xorg-driver-geode@lists.x.org
Subject: Re: [Xorg-driver-geode] Driver Perf LX800
Hello Christophe,
On T, 2010-07-06 at 15:54 +0200, Christophe Lindheimer wrote:
> I use a board with a Geode LX800.
>
> previous config was :
> Debian
> X Window System 7.1.1
> Video driver Vesa
>
> new config :
> Opensuse 11.2
> Updated Xserver 1.8.2
> Updated Geode Driver 2.11.8
>
> My application worked fine before, it is now unusable (too slow)
>
> I run a x11perf -rgbftext.
> Old config :81300 / s
> New config : 36000 / s
>
> I am rather newbie in X11, so I don't what are the resources used by
> x11perf in this case.
> From your point of view, the lost of perf is due to :
> 1. Issue within Geode driver.
> 2. due to the change of OS (maybe change in Cairo version of other
> stuff that would consume much more cpu ..)
Before you used a completely different driver that does most everything
in software on the CPU part of the chip. The current state of
xf86-video-geode is that many things are actually slower with hardware
acceleration due to many paths not being accelerated and the nature of
EXA acceleration - as soon as something can't be accelerated, it
involves slow memory copies to get the pixmap from video memory to
system memory to do that operation in software. And then the next
operation that can be accelerated makes it copy it from system memory to
video memory again, and so on. So we are currently losing all the gains
from hardware acceleration (and more) on memory copies, and in profiling
memcpy should be the main CPU consumer shown.
We are aware that glyph drawing became even slower since xorg-server-1.7
with xf86-video-geode, due to some improvements in EXA glyph cache
handling (for the benefit of many other GPU drivers), which now uses
some render operation that doesn't yet have hardware acceleration code
in the geode driver, among other things we do have accelerated. So we
suffer a pixmap ping-pong death (the glyph picture getting copied from
system memory to reserved video memory and back).
The focus will soon shift to performance in the revived xf86-video-geode
development, and glyph drawing is probably the first thing that will be
concentrated on. Big gains from probably just one new hwaccel path.
So hopefully it will be better in 2.11.10 version or so, whenever we get
to that, still work ongoing for 2.11.9, which concentrates on bug and
misrendering fixes.
If you require more performant graphics from the Geode right now, then I
suggest to use Option "NoAccel" "true" in your configuration, so that
always software rendering is forced. However this currently crashes and
can't be used - I hope to get this fixed later this week for the
upcoming 2.11.9 release (the crash fix is trivial, but no picture is
then shown until a VT switch to console and back, so that needs fixing
too before pushing fixes).
Of course once we shift focus on performance after 2.11.9 and fix things
there, you would eventually want to stop using NoAccel, once hardware
acceleration actually makes things faster again in a future release or
GIT repository state.
I will soon write a long e-mail to the list of what outstanding tasks we
have, with some details provided for each.
Feel free to monitor the list and actively test patches or GIT state :)
You can find some more information from
http://www.x.org/wiki/GeodeDriver - including more community resources
(IRC, bugzilla locations, GIT repository information, etc)
Regards,
Mart Raudsepp
_______________________________________________
Xorg-driver-geode mailing list
Xorg-driver-geode@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-geode
_______________________________________________
Xorg-driver-geode mailing list
Xorg-driver-geode@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-geode
