Mailinglist Archive: radeonhd (427 mails)
| < Previous | Next > |
Re: [radeonhd] [PATCH] EXA as default AccelMethod on r5xx
- From: Alex Deucher <alexdeucher@xxxxxxxxx>
- Date: Thu, 7 May 2009 11:09:33 -0400
- Message-id: <a728f9f90905070809r7859c160m89c0539800bc49c1@xxxxxxxxxxxxxx>
On Thu, May 7, 2009 at 5:40 AM, Matthias Hopf <mhopf@xxxxxxx> wrote:
For most modern desktops, EXA should be faster. It accelerates
antialiased text and render operations much better than XAA. There
are some cases where XAA is faster, but they tend to be things that
are not used on modern desktops. Also, due to limitations in XAA,
it's problematic to accelerate textured video when composite is
enabled. XAA provides no mechanism to migrate pixmaps into vram if
they are currently in system ram. It could be worked around by
manually allocating some vram and copying the pixmap to vram, but it's
not currently implemented. Additionally, only EXA supports
accelerated render transforms which means only EXA provides
accelerated screen rotation.
EXA performance has improved significantly in the few xserver releases
due to improvements in the core EXA code. Newer versions of KDE use
certain render operations that were not well accelerated with EXA on
older xservers, but that has mostly been fixed with changes to the EXA
core code. EXA doesn't work as well when the composite extension is
not available, so it will be slower when the DRI is disabled since the
driver depends on the drm for accelerated operations using the 3D
engine (EXA composite and textured video).
At this point no one is maintaining the XAA code in the xserver.
Offscreen pixmap support has been broken and disabled for the last
several xserver releases, so much of XAA ends up being software
rendering (which admittedly is pretty fast is a lot of cases). The
XAA acceleration driver hooks are also poorly matched to modern
hardware, making it very hard to support new chips with XAA. In
general EXA performs well for most users. At some point, we have to
switch to it if we want to flush out any remaining issues.
No resize yet. EXA provides acceleration for render which includes
anti-aliased text, alpha-blended blits, transforms (rotation,
scaling), etc.
Alex
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
On May 06, 09 17:26:11 -0400, Alex Deucher wrote:
On Wed, May 6, 2009 at 5:24 PM, Yang Zhao <yang@xxxxxxxxxx> wrote:
Now that DRI is on by default on r5xx, we might as well set EXA as
default instead of XAA.
What is the performance of EXA vs. XAA, what are the benefits?
For most modern desktops, EXA should be faster. It accelerates
antialiased text and render operations much better than XAA. There
are some cases where XAA is faster, but they tend to be things that
are not used on modern desktops. Also, due to limitations in XAA,
it's problematic to accelerate textured video when composite is
enabled. XAA provides no mechanism to migrate pixmaps into vram if
they are currently in system ram. It could be worked around by
manually allocating some vram and copying the pixmap to vram, but it's
not currently implemented. Additionally, only EXA supports
accelerated render transforms which means only EXA provides
accelerated screen rotation.
E.g. for the intel driver both EXA and UXA are currently extremely slow
compared to XAA (which is no longer officially supported), which is
giving us quite some headaches here at SuSE.
EXA performance has improved significantly in the few xserver releases
due to improvements in the core EXA code. Newer versions of KDE use
certain render operations that were not well accelerated with EXA on
older xservers, but that has mostly been fixed with changes to the EXA
core code. EXA doesn't work as well when the composite extension is
not available, so it will be slower when the DRI is disabled since the
driver depends on the drm for accelerated operations using the 3D
engine (EXA composite and textured video).
At this point no one is maintaining the XAA code in the xserver.
Offscreen pixmap support has been broken and disabled for the last
several xserver releases, so much of XAA ends up being software
rendering (which admittedly is pretty fast is a lot of cases). The
XAA acceleration driver hooks are also poorly matched to modern
hardware, making it very hard to support new chips with XAA. In
general EXA performs well for most users. At some point, we have to
switch to it if we want to flush out any remaining issues.
I don't think we already support framebuffer resizing - that would be a
reason to move to EXA.
No resize yet. EXA provides acceleration for render which includes
anti-aliased text, alpha-blended blits, transforms (rotation,
scaling), etc.
Alex
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
| < Previous | Next > |