EXA and damage performance problem
michel at daenzer.net
Thu Dec 1 03:47:14 PST 2011
On Die, 2011-11-29 at 14:33 +0100, Christoph Bartoschek wrote:
> [...] most of the time is spent in ExaCheckPolylines
> which is called by this chain:
> damagePolyRectangle -> miPolyRectangle -> exaPolylines -> ExaCheckPolylines
> I've measured the runtime of the steps in ExaCheckPolylines:
> ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
> int mode, int npt, DDXPointPtr ppt)
> EXA_FALLBACK(("to %p (%c), width %d, mode %d, count %d\n",
> pDrawable, exaDrawableLocation(pDrawable),
> pGC->lineWidth, mode, npt));
> exaPrepareAccess (pDrawable, EXA_PREPARE_DEST); // Step1: 55 s
> exaPrepareAccessGC (pGC); // Step2: 2.4 s
> pGC->ops->Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s
> exaFinishAccessGC (pGC); // Step4: 2.2 s
> exaFinishAccess (pDrawable, EXA_PREPARE_DEST); // Step5: 2.2 s
> We see that exaPrepareAccess needs most of the time. Is that expected?
> Inside there are several operations on the damage region. This makes
> damagePolyRectangle a quadratic algorithm.
> For N rectangles the damage region has O(N) rectangles. And for each
> Rectangle there are operations on the damage region. The result is O(N^2).
> Is it necessary to call exaPrepareAccess for each of the rectangles?
> Has anyone an idea how to improeve this?
The best solution would probably be to fix EXA or the app to hit
hardware acceleration paths instead of software fallbacks.
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
More information about the xorg-devel