[PATCH] Ensure blitter quiescience before reading pixels from the framebuffer

Michel Dänzer michel at tungstengraphics.com
Mon Jul 30 07:57:36 PDT 2007

On Mon, 2007-07-30 at 16:39 +0200, Bernardo Innocenti wrote:
> Michel Dänzer wrote:
> I depend on XAA because EXA is still unusably slow on all hardware
> I ever tried it with.  I wonder if there's someone with a different experience.

I wouldn't bother spending effort on EXA if it didn't work better for
me. Probably you're not using a composited desktop?

> >> I'm unsure how we could eliminate those 1x1 pixmaps used for solid fills,
> >> but they're certainly a big performance hit.  In some cases, we even upload
> >> them to the framebuffer by *dma*, then read the pixel with CPU :-)
> > 
> > Adam Jackson fixed that in GIT.
> This patch?
>  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=486fd4145aed93093d1f1655de40c0a8582bb8b1
> That's not really a fix, rather a workaround: we still upload the pixmap to the
> framebuffer, and we still allocate and initialize it in memory, which is also
> unfortunate.

Probably, but does it incur a measurable penalty? The CPU is supposed to
be ahead of the GPU anyway.

> > If there's still a measurable penalty in some cases with the above change,
> > this is probably the way to go.
> I always wanted to run oprofile on one of Cairo's benchmark to see how the
> overhead is distributed.  But Carl Worth already provided plenty of proof.

Can you be more specific? I've been following Carl's posts about i965
vs. EXA, but I don't remember reading anything about this particular
path having been identified as a bottleneck yet.

> The overhead is quite visible also with the naked eye: after walking through the
> server-side code for drawing one trapezoid, I'm actually surprised it still runs
> so fast :-)

I guess it's just not feasible to accurately estimate performance from
code inspection. It needs to be measured.

Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

More information about the xorg mailing list