[PATCH] exa: Split out some classic and driver allocated pixmap code into seperate files
Michel Dänzer
michel at daenzer.net
Wed Jul 22 15:08:07 PDT 2009
On Wed, 2009-07-22 at 23:45 +0200, Maarten Maathuis wrote:
> 2009/7/22 Michel Dänzer <michel at daenzer.net>:
> > On Wed, 2009-07-22 at 21:42 +0200, Maarten Maathuis wrote:
> >> - Rename exa_migration.c to exa_migration_classic.c
> >> - Create a few seperate functions and a few private function pointers.
> >> - Replace a few if conditions with a check for pExaPix->pDamage instead.
> >> - This is in preperation of a third scheme that lies somewhere in between.
> >
> > Some things like the file rename
>
> There will be a 2nd "migration" file, hence the rename.
Then it can be renamed in the patch introducing that.
> > seem gratuitous, but otherwise it looks okay. However, I don't have a
> > very good idea yet where you're going with the third scheme, might be
> > easier to review this patch together with that.
>
> I wanted to argue the interface changes first. In short it will be a
> migration scheme on top of driver pixmaps.
Nothing wrong with that in principle, but it's too vague to give a carte
blanche approval beforehand.
> This is because things like trapezoids should be done on system ram.
Actually, they (as anything else used by modern apps) should really be
done in hardware in the long run.
I assume you should have a working Gallium driver. Have you played with
the Gallium EXA state tracker? As time permits, I'm planning to work on
RENDER acceleration in it, and experiment with going beyond what our
drivers have accelerated so far - starting with simple stuff like solid
and gradient pictures, then possibly trapezoids etc. It would be great
if others beat me to doing this. :)
> The only major difference to "end users" will be that this will also handle the frontbuffer
> "migration".
I'm afraid that's again too vague.
> I'm expecting to perform better than a wfb based driver
That's not really hard in my experience. :)
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
More information about the xorg-devel
mailing list