[PATCH] exa: Split out some classic and driver allocated pixmap code into seperate files

[Maarten Maathuis]

2009/7/23 Michel Dänzer <michel at daenzer.net>:
> 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.

Ok.

>
>
>> > 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.

Agreed.

>
>> 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.

Long run is nice, unfortunately there is also today and ideally you
want to do sw rendering on normal memory and then move in.
Trapezoids just happens to be a case that shows this problem severely.

>
> 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. :)

I wouldn't call it working, last i checked. Still my priorities are
different right now,  which is avoiding performance regressions.
After that i can look into better solutions.

>
>
>> 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 have to deal with a tiled front buffer, a wfb-less solutions seems
preferable. So i have to copy parts (or the entire frontbuffer) into
sysram to do that. Otherwise fallbacks on the frontbuffer fail.
Classic exa doesn't do this.

>
>
>> I'm expecting to perform better than a wfb based driver
>
> That's not really hard in my experience. :)

Agreed.

>
>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
>