[Xorg-driver-geode] huge difference between hwaccel and no accel performance ??

[Mart Raudsepp]

Ühel kenal päeval, T, 2009-01-20 kell 17:09, kirjutas Justin Smith:
> Hi guys,
> 
> I am running some x11perf benchmarks and I see a huge performance
> difference in the wrong direction. The no accel option is much faster
> than the accelerated option. 
> Is the "No Accel" flag reversed, meaning "No Accel" is enabling the
> acceleration?

No, it is not reversed. If NoAccel is set, then EXA isn't initialized
and the acceleration architecture isn't really used.

The most common reason of accelerated being slower than software is when
the pixmap migration overhead exceeds the wins of acceleration. I'm not
sure this is the case here, but that's what has plagued many EXA using
drivers in the past.

Do you have any concrete things that are slower and are actually a
problem in real life modern applications?

Note that it is also quite important to be using a recent xorg-server,
as the EXA common code has received many improvements to it that improve
the matter in xorg-server-1.4, even more in 1.5 and also more in what
will become 1.6 (a RC2 or so should be out).


However for information, and a possible call for contributions:

One problem with the very latest xorg-server for geode seems to be the
glyph cache found in trunk and server-1.6-branch. It is a huge win for
many drivers, but it is my belief that its mask generation is causing it
to be a major loss for geode at this time. This however needs some
further verification.

In concrete I have commit 54184110f6f3e5d7276d5431e739a4fcf0c3523e to
xserver in mind. It adds a glyph cache and I believe it adds quite some
Pict_A8 (alpha channel only) PictOpAdd operations to that hot path,
which is currently not accelerated on geode, because the hardware does
not have pure alpha pixmap support.
A possible solution for that regression would be to make it possible for
the driver to instruct the EXA glyph infrastructure to always use ARGB
there, so we can accelerate the PictOpAdd composite operations, trading
the overhead to four time larger caches (though it seems its also
keeping ARGB caches as well anyway?). Another possibility could be to
hack together a way to convert A8 to ARGB in the hardware side. Adam
Jackson had some ideas in that area, but that could be a complementary
to cover the cases where we can't make the pixmaps passed to not be A8
in the first place - probably for other operations than glyph drawing.
Once someone fixes that regression, we can reap the benefits of the
glyph cache and end up with quicker glyph drawing than without glyph
cache in <xorg-server-1.6, as for other drivers.
All the other EXA changes in trunk and server-1-6-branch are probably a
win, so possibly just glyph drawing would be slower.

Note that some distributions have backported the EXA glyph changes and
more to their xorg-server-1.5 as well. Gentoo and Fedora come to mind,
iirc.


Regards,
Mart Raudsepp
Artec Design LLC