[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