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