[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:45:57 PDT 2009
On Thu, 2009-07-23 at 00:14 +0200, Maarten Maathuis wrote:
> 2009/7/23 Michel Dänzer <michel at daenzer.net>:
> > On Wed, 2009-07-22 at 23:45 +0200, Maarten Maathuis wrote:
> >
> > 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 forgot to mention: things that can't be done with the current EXA
driver interfaces could possibly be prototyped by wrapping around EXA,
and then later turned into new EXA driver interfaces as appropriate.
> I wouldn't call it working, last i checked.
In the worst case, the work can be done with softpipe until there's a
suitable HW driver.
> >> 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.
For this particular problem, something like Gallium texture transfers
could work (and could be used for it). Maybe just a new driver
PrepareAccess hook which provides information about the areas that need
to be read and that are written to.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
More information about the xorg-devel
mailing list