Gnome & EXA - Any progress ?

[Adam Jackson]

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:
>
>                radeon_drv.so`RADEONUploadToScreenMMIO
>                libexa.so`exaMoveInPixmap+0x9d
>                libexa.so`exaDrawableUseScreen+0x5b
>                libexa.so`exaCopyNtoN+0x1e9
>                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
>           412

This is the XCopyArea path, and exaMoveInPixmap means we're moving data from 
host to card memory, but we're correctly hitting the driver's UTS hook.

The MMIO in the name indicates that you don't have DRM active, which is sort 
of obvious since this is a dtrace session and I don't think the DRM support 
in Solaris is done yet.  I don't recall if hostdata blits (radeon word for 
DMA) work without DRM active, so this might be a memcpy upload.  Either way 
this is going as fast as it can go without DRM.

>                libfb.so`fbCopyNtoN
>                libexa.so`exaCopyNtoN+0x5be
>                libfb.so`fbCopyRegion+0x509
>                libfb.so`fbDoCopy+0x3d1
>                libexa.so`exaCopyArea+0x4f
>                Xorg`damageCopyArea+0x257
>                Xorg`fbShmPutImage+0x25b
>                Xorg`ProcShmPutImage+0x46e
>                Xorg`ProcShmDispatch+0x22a
>                Xorg`Dispatch+0x4c7
>                Xorg`main+0x50c
>                Xorg`0x46938c
>           641

This is the XShmPutImage path, which isn't special-cased in EXA yet.  I've 
done some preliminary work on it:

https://bugs.freedesktop.org/show_bug.cgi?id=2986

but it's not quite finished, in particular I seem to be nonconformant in a few 
cases.  Also it seems like DMA for PutImage isn't always a performance win in 
terms of raw numbers, but it probably reduces CPU usage a bit.  DMA for 
GetImage seems to be a win most of the time though.

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

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20051222/e8de53ae/attachment.pgp>