ati driver falling back to software

[Ray Van Dolson]

On Tue, Jun 17, 2008 at 09:49:33AM +0200, Michel Dänzer wrote:
> On Tue, 2008-06-17 at 00:14 -0700, Ray Van Dolson wrote:
> > 
> > I'm encountinger several situations where things seem to be dropping
> > back to software mode.
> > 
> >   1. With Composite mode enabled, XFCE Terminals are very slow
> >      resizing.  I see the following in my Xorg log:
> > 
> >         R300CheckComposite: Dest w/h too large (3200,1200).
> >         R300CheckComposite: Source w/h too large (3200,1200).
> >         exaCopyDirty: Pending damage region empty!
> > 
> >      I thought this issue had been fixed quite a while ago:
> > 
> >        http://www.mail-archive.com/xorg-driver-ati@lists.x.org/msg03386.html
> > 
> >      The code from this patch is in my copy of the driver... 
> 
> That change merely prevented the 3D engine coordinate limits to be
> imposed on driver operations using the 2D engine as well.
> 
> The question is whether this particular operation really requires the 3D
> engine or could be converted to a simpler one using the 2D engine. A
> full gdb backtrace from when R300CheckComposite() returns FALSE could
> help determine this.

I didn't get a chance to set this up this morning before heading off to
work but will do so this evening.

> BTW, is the xfwm4 compositor enabled? Is the resizing usable when the
> virtual screen size is <= 2560x2560?

The xfwm4 compositor is *disabled*.  I have just tried it with only one
screen attached and the virtual screen size set to 1600x1200.  I no
longer see the R300CheckComposite errors in my Xorg logfile and XFCE
Terminal resize is *definitely* better.  xchat resize seems about the
same though (aka pretty bad), even though I don't see any errors at all
in the Xorg logfile.

I tried with Composite both enabled and disabled but performance
appeared about the same (the Xorg option enabled -- I haven't run with
the xvwm4 compositor enabled at all yet).

An oprofile run resizing xchat for about 20 seconds still shows a lot
of calls to memcpy (being called by exaCopyDirty):

CPU: Athlon, speed 1733.56 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        image name               app name                 symbol name
-------------------------------------------------------------------------------
  2         0.0154  Xorg                     Xorg                     xf86_load_cursor_argb
  6         0.0462  Xorg                     Xorg                     xf86PostMotionEventP
  9         0.0693  radeon_drv.so            Xorg                     RADEONUploadToScreenCP
  18        0.1385  libc-2.8.so              Xorg                     realloc
  12958    99.7306  libexa.so                Xorg                     exaCopyDirty
12993    11.3274  libc-2.8.so              Xorg                     memcpy
  12993    100.000  libc-2.8.so              Xorg                     memcpy [self]
-------------------------------------------------------------------------------

Full oprofile logs here:

  http://www.bludgeon.org/~rayvd/xorg/opreport-l_1600.log
  http://www.bludgeon.org/~rayvd/xorg/opreport-c_1600.log (callgraph --
    warning this is 4.7MB)

So, I can reenable my second head and 3200x1600 virtual deskto and do a
backtrace still, but I am also interested in the poor xchat resize
performance at the virtual desktop size of 1600x1200... xchat resizing
(and other similar apps like the pdf viewer) are blazing fast on my
NVidia based laptops.

> 
> >   2. With composite mode still enabled, Firefox resizing gives me the
> >      following:
> > 
> >        R300CheckComposite: Component alpha not supported with source alpha and source value blending.
> 
> This is probably related to sub-pixel anti-aliased text and should be
> harmless, as EXA can still accelerate it in two passes.
> 

Thanks!