Ubuntu
xserver-xorg-video-ati package

[RV250] 32MB r200 DRI Slow - Fails to allocate texture

Bug #394402 reported by Pat Suwalski
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xserver-xorg-video-ati (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

I have a Dell Inspiron 600m with a 32MB Radeon 9000m, which uses r200 DRI. It has a 1400x1050 display, which with that little video RAM means I always disable compiz, and use metacity instead.

As of 9.04, the DRI has gotten very slow. Switching tabs in Firefox can take up to 6 seconds, if I run fullscreen.

pat@pat-laptop:~$ xdriinfo
Screen 0: r200

DRI appears to be running correctly, from Xorg.0.log:

(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables.
(II) RADEON(0): [drm] framebuffer handle = 0xe8000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): X context handle = 0x1
(II) RADEON(0): [drm] installed DRM signal handler
(==) RADEON(0): Using AGP 4x
(II) RADEON(0): [agp] Mode 0x1f000207 [AGP 0x8086/0x3340; Card 0x1002/0x4c66 0x1
028/0x011d]
(II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001
(II) RADEON(0): [agp] ring handle = 0xe0000000
(II) RADEON(0): [agp] Ring mapped at 0xb767a000
(II) RADEON(0): [agp] ring read ptr handle = 0xe0101000
(II) RADEON(0): [agp] Ring read ptr mapped at 0xb7679000
(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe0102000
(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0xb53db000
(II) RADEON(0): [agp] GART texture map handle = 0xe0302000
(II) RADEON(0): [agp] GART Texture map mapped at 0xb4efb000
(II) RADEON(0): [drm] register handle = 0xfcff0000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xebffe800 0x1fff0000
(II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0
(==) RADEON(0): Backing store disabled
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] dma control initialized, using IRQ 11
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
(WW) RADEON(0): DRI init changed memory map, adjusting ...
(WW) RADEON(0): MC_FB_LOCATION was: 0xebffe800 is: 0xebffe800
(WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xe07fe000
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xebffe800 0xebffe800
(II) RADEON(0): MC_AGP_LOCATION : 0xe07fe000
(II) RADEON(0): Direct rendering enabled
(II) RADEON(0): Render acceleration enabled for R200 type cards.
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Offscreen pixmap area of 6627328 bytes
(II) EXA(0): Driver registered support for the following operations:
(II) Solid
(II) Copy
(II) Composite (RENDER acceleration)
(II) UploadToScreen
(II) RADEON(0): Acceleration enabled
(...)
drmOpenByBusid: drmOpenMinor returns 11
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_make_current_read
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: enabled GLX_texture_from_pixmap with driver support
(II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so
(II) GLX: Initialized DRI GL provider for screen 0

I think there is a problem with memory mapping this r200. Running SDL games is very slow and choppy. For example, supertux2 runs at about 2fps. The console for supertux2 shows the following after every frame is drawn:

[driAllocateTexture:635] unable to allocate texture

This is what leads me to believe there is a problem with libdrm.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O Controller [8086:3340] (rev 03)
     Subsystem: Intel Corporation Device [8086:4541]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] [1002:4c66] (rev 01)
     Subsystem: Dell Device [1028:011d]

See original description
Revision history for this message
Bryce Harrington (bryce) wrote :

Hi pat-suwalski,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in libdrm (Ubuntu):
status: New → Incomplete
Revision history for this message
Pat Suwalski (pat-suwalski) wrote :

lspci -vvnn.

Revision history for this message
Pat Suwalski (pat-suwalski) wrote :

Xorg.0.log; xorg.conf not modified.

Bryce Harrington (bryce)
Changed in libdrm (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

more likely the dri driver to blame than the library..

affects: libdrm (Ubuntu) → mesa (Ubuntu)
Bryce Harrington (bryce)
affects: mesa (Ubuntu) → xserver-xorg-video-ati (Ubuntu)
Revision history for this message
Robert Hooker (sarvatt) wrote :

Have you tried forcing XAA instead of EXA? EXA with 32MB VRAM sounds painful..

Try adding this to your /etc/X11/xorg.conf

Section "Device"
     Identifier "radeon"
     Driver "radeon"
     Option "AccelMethod" "XAA"
EndSection

Bryce Harrington (bryce)
tags: added: jaunty
Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

A new version of the -ati driver is now available in Karmic.

This is a significant update to -ati which brings in kernel mode-setting
(currently disabled) and scores of fixes for DRI2, EXA, etc.

I've posted the new version of this driver to the following PPA,
would you mind testing it and seeing if it resolves the bug you
reported?

  https://edge.launchpad.net/~bryceharrington/+archive/ppa/+sourcepub/709908/+listing-archive-extra

If you're not running this release of Ubuntu, you can try booting the Karmic
LiveCD and loading the PPA onto it, and then log out/in to restart X.
ISOs are available at http://cdimages.ubuntu.com/releases/

After testing Karmic, report back here whether it's still an issue or not,
and if it is please post a fresh Xorg.0.log and 'dmesg' output.

Note there could be new bugs... please file these as new reports using
the command 'ubuntu-bug xorg'.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Pat Suwalski (pat-suwalski) wrote :

Indeed, switching to XAA seems snappier than EXA. I hadn't noticed the change because I was using a custom xorg.conf file around the time when EXA became the default.

I'm not sure there's much point in trying with EXA again in Karmic, assuming that EXA is still default and will still be slow.

However, it might be useful to have the driver not enter EXA mode on hardware with little video RAM...

Revision history for this message
Bryce Harrington (bryce) wrote :

> However, it might be useful to have the driver not enter EXA mode on hardware with little video RAM...

Indeed, there is a change included that causes it to default to XAA in certain circumstances (old hardware, low memory).

Revision history for this message
Bryce Harrington (bryce) wrote :

Have you had a chance to re-test on karmic? As per my previous comment, XAA is being forced as the default for several early cards which I suspect covers yours - please test and verify for us. If it's still an issue on karmic we can upstream this.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → New
status: New → Incomplete
importance: Undecided → Medium
Revision history for this message
Pat Suwalski (pat-suwalski) wrote :

Indeed, I grabbed the karmic build from 20090902, ran it as a live CD. This didn't have an xorg.conf, and the generated Xorg.0.log indicates that XAA was loaded automatically in lieu of EXA.

I then proceeded to try Firefox, but it crashes on startup, probably because the window is quite large and the compositing window manager ran out of video ram. But that's a different issue.

Bryce Harrington (bryce)
tags: removed: needs-xorglog
tags: removed: needs-lspci-vvnn
Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Confirmed
Bryce Harrington (bryce)
description: updated
Revision history for this message
Tormod Volden (tormodvolden) wrote :

The new XAA issue sounds like bug 426582.

Robert Hooker (sarvatt)
summary: - 32MB r200 DRI Slow - Fails to allocate texture
+ [RV250] 32MB r200 DRI Slow - Fails to allocate texture
Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Hi Pat,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 394402

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 394402 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/394402

Changed in xserver-xorg-video-ati (Ubuntu):
status: Confirmed → Incomplete
tags: added: needs-retested-on-lucid-by-june
Revision history for this message
Pat Suwalski (pat-suwalski) wrote :

Looks like it's been solved one way or another.

AccelMethod "XAA" no longer seems to do anything. Whether it's there or not, this is in the Xorg.log:

(II) RADEON(0): EXA: Driver will not allow EXA pixmaps in VRAM
(...)
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II) Solid
(II) Copy
(II) Composite (RENDER acceleration)
(II) UploadToScreen
(II) DownloadFromScreen

But there are no odd allocation errors, and it seems to work as well as it did when I was using XAA. So it seems solved.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.