EXA and damage performance problem

[Michel Dänzer]

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:
> 
> 
> void
> ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
>                    int mode, int npt, DDXPointPtr ppt)
> {
>    EXA_PRE_FALLBACK_GC(pGC);
>    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
>    EXA_POST_FALLBACK_GC(pGC);
> }
> 
> 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