Composite really slow

[Alex Deucher]

On Sun, 21 Nov 2004 14:59:27 -0800, Eric Anholt <eta at lclark.edu> wrote:
> On Sun, 2004-11-21 at 14:17, Dave Airlie wrote:
> 
> 
> > >
> > > It's all open source.  Someone just needs to find the time to port KAA
> > > and the related driver bits to xorg.  Unfortunately, it's not a
> > > trivial task.
> > >
> >
> > This may be a stupid question and let me clarify I've no idea about
> > XAA or KAA and have never looked at either of them, but can XAA not be
> > extended (incompatilbity maybe?) to be better at doing
> > render/composite stuff, I don't like the idea of rewriting drivers
> > just because some interface is not up to the job....
> 
> Basically no, in my opinion.  XAA wants you to have single rectangular
> space for offscreen memory at a specific bitdepth.  Rendering to
> offscreen pixmaps just means that you've got a 'y' value past the height
> of the screen -- when your driver is called on to do some rendering, you
> don't have information about the pixmap/window being drawn to.
> 
> This is totally not what we want for render.  For render, we *need* to
> be storing pixmaps of different bitdepth in offscreen memory (right now
> we upload them every single time, which is why XAA Render accel sucks
> for everything but text).  So, if we're storing non-screen-format
> pixmaps in offscreen memory, and we need to be able to do core rendering
> to them, we need to modify the interfaces to give the driver's core
> rendering code information about the depth, and we can't use a unified
> rectangular offscreen because an x/y/w/h doesn't make sense when the bpp
> differs.
> 
> If we just throw out the rectangular framebuffer, memory management
> becomes much easier.  And we can avoid the hacks we've got to deal with
> the fact that cards frequently have more memory than they can address in
> 2d operations if the starting offset is the beginning of framebuffer.
> 
> This is the main thing that's important about KAA, in my opinion -- it
> starts from the right basis, that being linear memory management.  It
> also offers a simpler and smaller driver interface, which I think is
> also a feature.
> 

While we are at it we ought to add proper support for tiled
framebuffers as well as they are becoming more and more prevalent.

Alex

> --
> Eric Anholt                                eta at lclark.edu
> http://people.freebsd.org/~anholt/         anholt at FreeBSD.org
>            Thank goodness for the 22nd Amendment
> 
>