On Thu, May 7, 2009 at 5:40 AM, Matthias Hopf wrote:

On May 06, 09 17:26:11 -0400, Alex Deucher wrote:

...

On Wed, May 6, 2009 at 5:24 PM, Yang Zhao 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@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Thu, May 7, 2009 at 1:37 PM, Matthias Hopf wrote:

On May 07, 09 11:09:33 -0400, Alex Deucher wrote:

...

On Thu, May 7, 2009 at 5:40 AM, Matthias Hopf wrote:

...

On May 06, 09 17:26:11 -0400, Alex Deucher wrote:

...

On Wed, May 6, 2009 at 5:24 PM, Yang Zhao 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

The issue is - as in most cases - that it "should be" is not necessarily "is" :-P

...

not currently implemented.  Additionally, only EXA supports accelerated render transforms which means only EXA provides accelerated screen rotation.

That's a good point. Even though rotation isn't widely used.

...

...

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

I'm talking about upstream current git, xserver and driver. UXA, DRI2, GEM, and KMS enabled. The intel driver performance is abominable at the moment.

Before switching I just want to hear from real life users that this is actually working well. Otherwise no objections.

FWIW, I've been using EXA for over a year now, and at least for me, it performs much better than XAA for what I do (mostly coding and web browsing). Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Hi Conn,

  Back when I was using a machine that had a 5xx and was using FEA/CFD software that required meshing grids and viewing them, XAA spanked EXA on performance because it had the hardware accelerated diagonal line function. When viewing 1.5 million nodes connected together lines to form pyramid shaped cells that particular feature helped a lot.

Yes I have experienced this case, too. Especially problematic are cases where you toggle between accelerated and software-fallback situations, where almost all time is wasted copying pixmap contents arround. What would help EXA a lot would probably be a better decision if something is really worth migration to VRAM. I have some ideas which probably could help to avoid those worst-cases altogether, but I don't have time or the knowledge needed to implement it. - Clemens -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Hi Matthias,

I'm talking about upstream current git, xserver and driver. UXA, DRI2, GEM, and KMS enabled. The intel driver performance is abominable at the moment. Yes it really is - but UXA is not EXA ^^. The intel driver has been in really _bad_ shape (even when using EXA), only slowly reaching a useable state.

Before switching I just want to hear from real life users that this is actually working well. Otherwise no objections. Intel+EXA worked well on my previous setup (Xorg-server-1.3.0), so considering the time it had to mature I guess its really the best choise by now.

- Clemens -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Yang Zhao wrote:

2009/5/6 Yang Zhao :

...

Now that DRI is on by default on r5xx, we might as well set EXA as default instead of XAA.

AFAICS there's no major opposition towards this, so I'll go ahead and commit it sometime on Monday.

XAA however does better when resizing windows (grab the edge of a terminal window and start zooming around: EXA will show stuttering behaviour, XAA is smooth). But this is the only gripe I have regarding EXA :). Cheers, -- Thomas E. Spanjaard tgen@netphreax.net tgen@deepbone.net

2009/8/17 Matthias Hopf :

What do you think with enabling DRM by default on r6xx? Is this stable enough? Not talking about the DRI driver itself, just about access to the kernel module.

I was going to suggest this as well, but wanted to take another look at the no-DRM fallback code first. I seem to remember something about not being able to elegantly fallback to ShadowFB when DRM is enabled but unavailable, and that may be an issue if true. It's definitely stable enough for everyday use, though. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

2009/8/17 Matthias Hopf :

What do you think with enabling DRM by default on r6xx? Is this stable enough? Not talking about the DRI driver itself, just about access to the kernel module.

EXA on r6xx/r7xx causes corruptions in Qt4 applications and in audacity. We shouldn't switch to EXA as default until that's fixed. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org