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

[Justin Smith]

forgot to cc the list ... forwarding.

---------- Forwarded message ----------
From: Justin Smith <justinsmith2009 at gmail.com>
Date: Thu, Jan 22, 2009 at 4:59 PM
Subject: Re: [Xorg-driver-geode] huge difference between hwaccel and no
accel performance ??
To: Mart Raudsepp <mart.raudsepp at artecdesign.ee>


Hi Mart,

Thanks for your detailed response.

Another followup question I have is how to get the xv maximum image size
from 1k x 1k to 2k x 2k. Is there a patch available already?
I have found couple of bugs, one in 2.11.0 and one in the last checkin that
you have done - what is the best way to report bugs.

Thanks,

Justin


On Wed, Jan 21, 2009 at 4:02 AM, Mart Raudsepp <mart.raudsepp at artecdesign.ee
> wrote:

> Ü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
>
> _______________________________________________
> Xorg-driver-geode mailing list
> Xorg-driver-geode at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-geode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-driver-geode/attachments/20090122/1ba4b087/attachment.html