EXA

Jesse Barnes jbarnes at virtuousgeek.org
Mon Aug 6 18:25:13 PDT 2007


On Monday, August 6, 2007 8:55 am Michel Dänzer wrote:
> On Mon, 2007-08-06 at 17:43 +0200, Lukas Hejtmanek wrote:
> > On Mon, Aug 06, 2007 at 05:02:36PM +0200, Michel Dänzer wrote:
> > > >     800 reps @  11.4473 msec (    87.4/sec): ShmPutImage
> > > > 500x500 square
> > >
> > > I'm getting better results and a profile that's wildly different
> > > from yours. Please try to find out where memcpy is getting called
> > > from for you.
> >
> > If sysprof can be trusted, it has the following calls sequence:
> >
> > ProcShmPutImage
> > miShmPutImage
> > damageCopyArea
> > exaCopyArea
> > fbDoCopy
> > fbCopyRegion
> > exaCopyNtoN
> > exaDoMigration
> > exaMoveOutPixmap
> > exaCopyDirtyToSys
> > exaMemcpyBox
> > memcpy
>
> Not sure why exaCopyNtoN would fall back to software here, can you
> find out?

I think this is my fault.  In fixing up some of the tiled front buffer 
rendering issues I saw, I read the docs a bit too literally and limited 
tiled blits & solid fills to the first 4k of address space, which meant 
every operation would fall back to the CPU.

I've since reverted that change and reintroduced the solid & copy 
rendering bugs, but at least we're not hiding them anymore...

As far as I can tell, the Solid & Copy routines should work correctly 
when targetting tiled destinations (pitch gets divided by 4 as it 
should, just like in the Mesa and XAA cases), but things still don't 
look right, so there's more debugging to do.  That and the composite 
hook is still broken with tiled targets on 965...

Jesse



More information about the xorg mailing list