Render Acceleration on ATI r100/r200 chips

[Eric Anholt]

On Fri, 2004-09-10 at 21:06, Cameron wrote:
> Did you enable acceleration for render in your xorg.conf?
> 
> -Cameron
> 
> On Friday 10 September 2004 8:50 pm, Michel Dänzer wrote:
> > On Thu, 2004-09-09 at 21:08 +0200, GhePeU wrote:
> > > I see in the Changelog that Render Acceleration is now supported in
> > > radeon open source driver (for chips r100/r200, I assume this is valid
> > > for my radeon 7500 rv200 chip that should be basically a r100 with some
> > > improvements, am I wrong?), but at present the new features granted by
> > > composite extension are unusable because everything become awfully slow.
> > > Is this due to the still uncomplete support and with future release
> > > there will be speed improvements almost to the level of same-age nvidia
> > > cards or is this a technical limit of my card and I should consider
> > > upgrading?
> >
> > The former.

Render acceleration is already on by default for the ati driver.  The
NVIDIA binary driver is all you have to use the RenderAccel option for
that I've heard of.

Let me say this once, and hopefully I won't have to again (hah!).  XAA
(XFree86 Acceleration Architecture, what your 2d drivers are based on)
isn't cut out for accelerating the Render extension.  That's why
xcompmgr -c or -s or -f or uncover or the various other things
everyone's using are so slow, even with the render acceleration we've
written.  The XAA Render hook is good for text -- we see around
order-of-magnitude improvements for that, but it's just not good enough
for general use.

I would like to work on bringing in a new acceleration architecture for
our next release.  I really like the KAA model -- a few hooks for the
things that matter (So far that's been solid fill, copy area, render,
and trapezoids) and the possibility for setup for acceleration to fail,
and decompose other operations into those operations when possible.  The
important part, though, is linear memory management, which will let us
make Render fly.  There's a ton of work to be done, even if we agreed on
this path.  Off the top of my head, it includes a better memory manager,
general tile acceleration, a proper trapezoids hook and working sample
implementation(s), the multihead stuff that XAA handles, better xv and
render acceleration helpers, and at least one sample driver converted.

-- 
Eric Anholt                                eta at lclark.edu          
http://people.freebsd.org/~anholt/         anholt at FreeBSD.org