[Xorg] Solicitation of screen shots of new facilities in action...
eta at lclark.edu
Fri Aug 13 15:24:47 PDT 2004
On Fri, 2004-08-13 at 12:26, Jim Gettys wrote:
> No, it shouldn't be dog slow.
Well, it shouldn't, if you have an acceleration architecture that's had
much work done, or been designed, to support Render with it. XAA
doesn't fall under that category. XAA doesn't accelerate untransformed
non-repeating source copies with the source in framebuffer (well,
actually *anything* with source in framebuffer), which is what you'll be
doing frequently with xcompmgr, and I believe with automatic updates as
well. We could fix this easily by adding code to XAA's Composite
function to check for that case and use the normal 2D acceleration, but
we don't yet. If we had got things up and running faster than we did, I
would have tried to finish up the bit of code I have to do this and push
it in, but there have been plenty of other things to work on.
As it is, a normal window update, with the window in offscreen pixmap
cache will involve normal acceleration into the backing pixmap in
framebuffer. Damage reports that, and xcompmgr copies in software to
its backbuffer (since it's this unaccelerated operation). Since the
backbuffer is probably in framebuffer as well, you then have to copy in
software from framebuffer to frontbuffer. Ouch. You actually will
likely get better performance after you use it for a while and XAA's
offscreen memory management results in a window or backbuffer pixmap
being kicked out of framebuffer for the rest of its life as new pixmaps
come in (except, of course, if those new pixmaps are also windows, in
which case you get the same pain in a new location).
My comments on XAA are as I understand things from reading the code as
best I could, and anecdotal evidence. I'd be happy to find out that the
situation is better, but I highly doubt it.
My plan is to do a lot of work on KAA this fall in the area of offscreen
memory management and accelerating Render trapezoids, and to work on
integrating what results from that into X.Org for the next release if
possible, while retaining XAA for non-updated drivers.
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
More information about the xorg