Gnome & EXA - Any progress ?
Alan.Coopersmith at Sun.COM
Thu Dec 22 16:45:14 PST 2005
Adam Jackson wrote:
> 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.
Right - work in progress - hoping to have DRM for Radeon on Solaris sometime
next year. (dtrace for FreeBSD is also a work in progress, or we could get
a dtrace of a session with DRM that way.) Given the code, I figured it was
close enough to track down which calls were taking which paths.
> 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:
I tweaked the dtrace script to parse the first two arguments as DrawableRecs
to try to narrow this down further.
> - drawable too big for the card's limits (unlikely, 2048^2 on radeon), or
Doesn't seem to be this one - even tiny calls are going the slow path.
Most common sizes for each path:
196 519 2
144 519 2
284 519 3
11 19 13
16 16 40
5 3 46
22 50 54
145 32 76
1536 64 119
45 50 162
48 49 382
45 51 424
(My laptop screen is only 1400x1050, so someone's operating on bigger
than screen size chunks, but a lot of 1-pixel high calls went through
fbCopyNtoN to, as well as the 5x3 you can see above.)
> - driver's PrepareCopy hook fails, which for radeon means:
> - dest drawable isn't 8, 16, or 32bpp, or
That seems to be part of the problem - depth seems to be 1 for
about 1/6 of the calls taking the slow path (first column is
the depth member of the dstDrawable):
> - source or destination drawable fail some alignment checks (see
> RADEONGetOffsetPitch for details).
If my traces get to RADEONPrepareCopyMMIO, it seems to pass all those checks.
Most of the calls to fbCopyNtoN don't seem to be preceded by a
RADEONPrepareCopyMMIO call though. (Or at least not paired - of the
1831 calls in that sample to fbCopyNtoN, there were only 87 that
had their own RADEONPrepareCopyMMIO call.)
It looks like the biggest culprit is simply the pixmaps aren't on the video
card - tracing the return value from exaPixmapIsOffscreen gives:
This causes the exaGetOffscreenPixmap call to return NULL to exaCopyNtoN,
which makes it fall down to the fallback.
(Which I suppose makes the question, why are these offscreen? The sticker
on my laptop claims my Radeon has 128Mb of RAM.)
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
More information about the xorg