Gnome & EXA - Any progress ?

[Eric Anholt]

On Thu, 2005-12-22 at 16:21 -0500, Adam Jackson wrote:
> On Thursday 22 December 2005 15:26, Alan Coopersmith wrote:
> > I have RC2 on my laptop at the moment with Radeon Mobility 9700 and EXA
> > turned on.   It's not built with MMX support, so I traced on fbCopyNtoN
> > instead, since that's what calls fbCopyAreammx if built with MMX.   I had a
> > GNOME 2.6 session up, started up a gnome-terminal and firefox, moved
> > windows around, switched some workspaces and the stack trace distribution I
> > got for calls to fbCopyNtoN vs. RADEONUploadToScreenMMIO was:

...

> >                libfb.so`fbCopyNtoN
> >                libexa.so`exaCopyNtoN+0x5be
> >                libfb.so`fbCopyRegion+0x509
> >                libfb.so`fbDoCopy+0x3d1
> >                libexa.so`exaCopyArea+0x4f
> >                Xorg`damageCopyArea+0x257
> >                Xorg`ProcCopyArea+0x1fe
> >                Xorg`Dispatch+0x4c7
> >                Xorg`main+0x50c
> >                Xorg`0x46938c
> >          6263
> 
> This one is probably the culprit, due to the hitcount.  EXA is falling back to 
> software copies (fbCopyNtoN, which uses either the MMX code or the naive 
> fbBlt) for some reason, and according to the code it's either:
> 
> - drawable too big for the card's limits (unlikely, 2048^2 on radeon), or
> - driver's PrepareCopy hook fails, which for radeon means:
>   - dest drawable isn't 8, 16, or 32bpp, or
>   - source or destination drawable fail some alignment checks (see
>     RADEONGetOffsetPitch for details).
> 
> So, there's work to be done here, on a few axes, and it sort of depends which 
> of these fallbacks are being hit.

Or, EXA has decided that either the source or the destination doesn't
deserve to be in framebuffer memory (and if the source is in memory, you
lose really badly).  This brings us back to the lame heuristics we've
got currently, which I've ranted about previously.

At the last xdpdx meeting, we developed plans for new memory management
for DRI in general and for just EXA in the near tearm.  I need to get
around to doing that.

-- 
Eric Anholt                                     eta at lclark.edu
http://people.freebsd.org/~anholt/              anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20051222/20e0599b/attachment.pgp>