Gnome & EXA - Any progress ?

[Alan Coopersmith]

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.


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

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:

RADEONUploadToScreenMMIO calls:
       196      519                2
       144      519                2
       284      519                3
        11       19               13

fbCopyNtoN calls:
        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):

RADEONUploadToScreenMMIO calls:
        24               92
fbCopyNtoN calls:
         1              594
        24             2544

>   - 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:
   RADEONUploadToScreenMMIO calls:
         0                1
         1              100
   fbCopyNtoN calls:
         0             4657

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