radeon and EXA

Michael Olbrich michael-olbrich at web.de
Wed Sep 21 03:03:39 PDT 2005

On Tue, Sep 20, 2005 at 02:35:04PM -0400, Michel Dänzer wrote:
> On Tue, 2005-09-20 at 10:12 +0200, Michael Olbrich wrote:
> > 
> > Thinkpad with Radeon Mobility 7500
> > Kernel 2.6.13-mm1
> > debian experimental xorg packages ( + EXA and
> > radeon_drv from cvs
> How much video RAM, what resolution and depth? It might be useful to see
> your config and log files.

(--) RADEON(0): VideoRAM: 32768 kByte (64 bit DDR SDRAM)
(--) RADEON(0): Virtual size is 1400x1050 (pitch 1408)
(--) Depth 24 pixmap format is 32 bpp

The relevant part of my config:
Section "Extensions"
        Option "Composite" "enable"

Section "Device"
        Option     "AGPMode"            "4"     # <i>
        Option     "AGPFastWrite"       "on"    # [<bool>]
        Option     "EnablePageFlip" "on"
        Identifier  "Radeon0"
        Driver      "radeon"
        VendorName  "ATI Technologies Inc"
        BoardName   "Radeon Mobility M7 LW [Radeon Mobility 7500]"
        BusID       "PCI:1:0:0"
        Option      "AccelMethod"       "EXA"
        Option      "DynamicClocks"     "on"
        Option      "BackingStore"      "off"
        Option      "BIOSHotkeys"       "on"

oh, and I found something interesting in my log. Not sure if that's a
problem (whole log appended):
(II) LoadModule: "radeon"
(II) Reloading /usr/X11R6/lib/modules/drivers/radeon_drv.so
(WW) ****INVALID MEM ALLOCATION**** b: 0xe0000000 e: 0xe8000000 correcting^G
(II) window:
        [0] -1  0       0xe0000000 - 0xe7ffffff (0x8000000) MX[B]
(II) resSize:
        [0] -1  0       0x00000000 - 0xffffffff (0x0) MX[B]
(II) window fixed:
        [0] -1  0       0xe0000000 - 0xe7ffffff (0x8000000) MX[B]
(WW) ****INVALID IO ALLOCATION**** b: 0x3000 e: 0x3100 correcting^G
(II) window:
        [0] -1  0       0x00003000 - 0x000030ff (0x100) IX[B]
        [1] -1  0       0x00003400 - 0x000034ff (0x100) IX[B]
        [2] -1  0       0x00003800 - 0x000038ff (0x100) IX[B]
        [3] -1  0       0x00003c00 - 0x00003cff (0x100) IX[B]
(II) resSize:
        [0] -1  0       0x00000000 - 0xffffffff (0x0) IX[B]
(II) window fixed:
        [0] -1  0       0x00003000 - 0x000030ff (0x100) IX[B]
        [1] -1  0       0x00003400 - 0x000034ff (0x100) IX[B]
        [2] -1  0       0x00003800 - 0x000038ff (0x100) IX[B]
        [3] -1  0       0x00003c00 - 0x00003cff (0x100) IX[B]
Requesting insufficient memory window!: start: 0x3000 end: 0x30ff size 0xc0120100
Requesting insufficient memory window!: start: 0x3400 end: 0x34ff size 0xc0120100
Requesting insufficient memory window!: start: 0x3800 end: 0x38ff size 0xc0120100
Requesting insufficient memory window!: start: 0x3c00 end: 0x3cff size 0xc0120100
(EE) Cannot find a replacement memory range

> > The basics are pretty much what was reported so far.
> > Without xcompmgr scrolling is rather unusable.
> > With xcompmgr scrolling is better (but not as good as XAA) but switching
> > between desktops (and windows to a lesser extend) is very slow.
> Do you have Eric Anholt's latest exaGlyphs improvements? They made a big
> difference here, at least for scrolling.

I have it now.
Another point about scrolling: a tiled background seems to make it a lot
> > What worries me most is the influence of CPU load. I've been running a
> > compiler in background and the system was more or less unusable.
> > Switching between windows takes seconds. The clock on my panel (which is
> > usually the last thing that still works when the load gets to high)
> > sometimes skips 2-3 second. Even the cursor gets jerky. While that can
> > be improved with a higher priority for the xserver it is far from the
> > responsiveness I get with XAA.
> Note that EXA vs. XAA doesn't have any direct impact on how cursor
> movement is handled, unless you're using SW cursor maybe.

I'm not, although with EXA it sometimes feels like I am.
(II) RADEON(0): Using hardware cursor (offset 25640960)

> > (This is all with xcompmgr which is what we want EXA for anyway, right?)
> If you don't run the compile with nice, it might help to renice the X
> server and/or xcompmgr to -1 or something.

Hmmm, seems to help a bit.

A few more observations:
Most actions have a warmup phase (for the lack of a better word):
Draging a window or scrollbar starts with on or two jumps before running
After some time the smooth part doesn't come. Everything is very slow
until I switch desktops or restart xcompmgr. I have no idea what
triggers the problem nor am I sure if that's really what stops it.
Switching desktops takes forever. The clock on my pannel usually skips 4

And very annoying: pressing a key during the mentioned "warmup phase"
usually results in getting it twice. High cpu load makes it worse. High
priority for xcompmgr makes it better.


More information about the xorg mailing list