[RS100] desktop became slow after upgrading to Lucid

Bug #544496 reported by Matej Kenda on 2010-03-22
148
This bug affects 28 people
Affects Status Importance Assigned to Milestone
xserver-xorg-driver-ati
Won't Fix
Medium
Debian
Won't Fix
Medium
xserver-xorg-video-ati (Ubuntu)
Low
Unassigned
Nominated for Lucid by Matej Kenda

Bug Description

[Problem]
Switching to KMS as the default for radeon causes a performance regression, seen with compiz enabled or with 3D games.

This is caused by the new vline support which prevents tearing with Xv but reduces performance as a consequence.

[Workarounds]
Pick your poison:
* Disable compiz
* Disable kms (grub: radeon.modeset=0)
* Patch to revert the vline change
* Wait for DRI2 page flipping support which will give better results for full-screen apps

Situation on Maverick is worse on some chips.

[Original Report]
Binary package hint: xserver-xorg-video-ati

I upgraded my laptop to Lucid somewhere around Alpha 2.

The first thing that I noticed is that the display was much slower than in Karmic. I tried to run with and without modesetting, but there is no difference.

Compositing worked fine in Karmic, however it is useless in Lucid, which means that performance of both 2D and 3D regreessed.

CPU load of Xorg is high as soon as there is some activity on the screen.

I was also trying to enable different options in xorg.conf (http://dri.freedesktop.org/wiki/ATIRadeon) with no success.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: fd17ddbce499316ea5512e53f255b019
CheckboxSystem: 79d4f9e1ffc31ae443cb2de53cd33e42
Date: Mon Mar 22 21:21:40 2010
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
Lsusb:
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Compaq Presario
Package: xserver-xorg-video-radeon 1:6.12.191-1ubuntu2
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   3.3V 32-bit PC Card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic root=UUID=737a8285-476e-4d78-9849-96d939d64b95 ro single
ProcEnviron:
 LANG=sl_SI.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.32-16-generic i686
dmi.bios.date: 11/25/2003
dmi.bios.vendor: Phoenix
dmi.bios.version: 0F0B
dmi.board.name: 07D4h
dmi.board.vendor: Compaq
dmi.board.version: KBC Revision: 1328
dmi.chassis.type: 10
dmi.chassis.vendor: Compaq
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenix:bvr0F0B:bd11/25/2003:svnCompaq:pnPresario:pvr0100:rvnCompaq:rn07D4h:rvrKBCRevision1328:cvnCompaq:ct10:cvrN/A:
dmi.product.name: Presario
dmi.product.version: 0100
dmi.sys.vendor: Compaq
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-16-generic
---
Architecture: i386
CheckboxSubmission: fd17ddbce499316ea5512e53f255b019
CheckboxSystem: 79d4f9e1ffc31ae443cb2de53cd33e42
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
Lsusb:
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Compaq Presario
Package: xserver-xorg-video-ati 1:6.12.191+git20100314.67e81c8f-0ubuntu0sarvatt
PackageArchitecture: i386
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   3.3V 32-bit PC Card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic root=UUID=737a8285-476e-4d78-9849-96d939d64b95 ro quiet lapic splash
ProcEnviron:
 LANG=sl_SI.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
Tags: lucid lucid
Uname: Linux 2.6.32-16-generic i686
UnreportableReason: This is not a genuine Ubuntu package
UserGroups: adm admin audio cdrom dialout dip fax floppy fuse lpadmin netdev plugdev powerdev scanner tape video www-data
dmi.bios.date: 11/25/2003
dmi.bios.vendor: Phoenix
dmi.bios.version: 0F0B
dmi.board.name: 07D4h
dmi.board.vendor: Compaq
dmi.board.version: KBC Revision: 1328
dmi.chassis.type: 10
dmi.chassis.vendor: Compaq
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenix:bvr0F0B:bd11/25/2003:svnCompaq:pnPresario:pvr0100:rvnCompaq:rn07D4h:rvrKBCRevision1328:cvnCompaq:ct10:cvrN/A:
dmi.product.name: Presario
dmi.product.version: 0100
dmi.sys.vendor: Compaq
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-16-generic

[lspci]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility U1 [1002:4336]
     Subsystem: Compaq Computer Corporation Device [0e11:00b0]

Created an attachment (id=33350)
Xorg.0.log

This is caused by the new vline support. Frame rates have dropped due to the new vline support which prevents tearing. I suppose we could add an option to disable it.

Probably better would be to implement DRI2 page flipping support, which should allow eliminating tearing with little if any performance impact (at least with triple buffering), at least for fullscreen apps.

I made a local branch in git off of the vline commit, reverted it in the branch, and merged master onto the branch. Performance is restored, plus everything seems a little bit faster than before! (Maybe Pauli's stuff causing that? Or maybe hallucinating....)

From what I understand about vline, it's something I want. Is the performance hit something that an app (like 'torcs') could find a workaround for, or is the hit unavoidable?

For now I will keep merging updates to my "no-vline" branch.

(In reply to comment #4)
> I made a local branch in git off of the vline commit, reverted it in the
> branch, and merged master onto the branch. Performance is restored, plus
> everything seems a little bit faster than before! (Maybe Pauli's stuff causing
> that? Or maybe hallucinating....)
>

His changes only affect Xv.

> From what I understand about vline, it's something I want. Is the performance
> hit something that an app (like 'torcs') could find a workaround for, or is the
> hit unavoidable?

It avoids tearing on GL buffers swaps by waiting until the scanout is past the part of the screen being updated.

Updating this report with more recent experiences:

On Mar. 8 I upgraded from Mesa 7.8 (git be1b7d1) to Mesa 7.9-devel (git 3ca9336), and notice an all around performance increase. Immediately following that, I built, installed, and booted the newly-released 2.6.34-rc1 kernel.

Just booting that new kernel to a command-line-only runlevel revealed a noticeable performance improvement. Running X revealed that the performance gains were across the board: everything was running faster.

I've been building my own xf86-video-ati packages with the "vline" feature reverted, but with these performance gains I decided to test it again.

I built and ran radeon from git commit 3a44f1c (Mar. 9) in two versions -- one with "vline" reverted, and one with "vline" included. As before, the "vline" version is perceivably more sluggish than the version with that feature reverted. However, the most dramatic differences in my original post here were seen in the game 'torcs'; when I tried that game again, it was playable this time (last time, the sluggishness made it nearly impossible to play). Interestingly, I reported before that the 'torcs' frame rate seemed to be capped at 30 fps (half my monitor's vert refresh rate), but this time the game was often able to jump into the 50 fps range for short bursts.

Other apps I've been testing with, besides 'torcs', are also affected negatively... but less noticeably so.

The "vline" feature itself definitely works as intended. No cutting/tearing ever occurs. I wasn't having bad problems with tearing without "vline," but in games like 'torcs' (and even 'prboom') the difference is noticeable. I definitely prefer the "vline" version for clarity, but the "no-vline" version still outperforms it enough that I'll be sticking with my git branch with the reversion for a little while longer.

I am using quite fast hardware here, Radeon HD 4850, so I wouldn't be surprised if less powerful cards were impacted more seriously.

Binary package hint: xserver-xorg-video-ati

I upgraded my laptop to Lucid somewhere around Alpha 2.

The first thing that I noticed is that the display was much slower than in Karmic. I tried to run with and without modesetting, but there is no difference.

Compositing worked fine in Karmic, however it is useless in Lucid, which means that performance of both 2D and 3D regreessed.

CPU load of Xorg is high as soon as there is some activity on the screen.

I was also trying to enable different options in xorg.conf (http://dri.freedesktop.org/wiki/ATIRadeon) with no success.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: fd17ddbce499316ea5512e53f255b019
CheckboxSystem: 79d4f9e1ffc31ae443cb2de53cd33e42
Date: Mon Mar 22 21:21:40 2010
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
Lsusb:
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Compaq Presario
Package: xserver-xorg-video-radeon 1:6.12.191-1ubuntu2
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   3.3V 32-bit PC Card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic root=UUID=737a8285-476e-4d78-9849-96d939d64b95 ro single
ProcEnviron:
 LANG=sl_SI.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.32-16-generic i686
dmi.bios.date: 11/25/2003
dmi.bios.vendor: Phoenix
dmi.bios.version: 0F0B
dmi.board.name: 07D4h
dmi.board.vendor: Compaq
dmi.board.version: KBC Revision: 1328
dmi.chassis.type: 10
dmi.chassis.vendor: Compaq
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenix:bvr0F0B:bd11/25/2003:svnCompaq:pnPresario:pvr0100:rvnCompaq:rn07D4h:rvrKBCRevision1328:cvnCompaq:ct10:cvrN/A:
dmi.product.name: Presario
dmi.product.version: 0100
dmi.sys.vendor: Compaq
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-16-generic

Matej Kenda (matejken) wrote :
Matej Kenda (matejken) wrote :

I installed packages from xorg-edgers (https://launchpad.net/~xorg-edgers). There is no difference in performance.

I will attach log files for updated installation.

tags: added: apport-collected
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Bryce Harrington (bryce) on 2010-03-22
summary: - ATI Radeon Mobility U1: desktop became slow after upgrading to Lucid
+ [RS100] ATI Radeon Mobility U1: desktop became slow after upgrading to
+ Lucid
summary: - [RS100] ATI Radeon Mobility U1: desktop became slow after upgrading to
- Lucid
+ [RS100] desktop became slow after upgrading to Lucid
Bryce Harrington (bryce) on 2010-03-22
description: updated
Changed in xserver-xorg-video-ati (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Changed in xserver-xorg-driver-ati:
status: Unknown → Confirmed
Matej Kenda (matejken) wrote :

I tried to apply two of the workarounds listed in the description.

* Disable compiz: Disabled, desktop is still very slow (although usable)
* Disable kms (grub: radeon.modeset=0): Enabling or disabling doesn't have impact on performance

Bryce Harrington (bryce) on 2010-03-24
description: updated

Hello I reported the same bug here(https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/531372), but Bryce Harrington marked it as invalid. This is the same bug but I have another card model. However, when I disabled KMS(through grub), 3D performance remained same like in Karmic.

Matej Kenda (matejken) wrote :

Marián, on my computer, disabling the KMS doesn't have much effect on performance.

I am not concerned a lot about 3D performance (although it'd be nice if it was the same as on Karmic). 2D (desktop) performance is affected a lot as well.

Bryce Harrington (bryce) wrote :

I have a driver upload coming soon which purports to include two performance boosts:

    - r6xx/r7xx: fix domain handling in accel code. Improves GetImage
      performace by a factor of ~10.
    - Allocate Xv buffers to GTT. This is nice performance boost for Xv
      under KMS.

Don't know if these will fully resolve this bug or just portions of it, or nothing at all. But please upgrade to it and let me know how it goes.

1 comments hidden view all 123 comments
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-ati - 1:6.12.192-2ubuntu1

---------------
xserver-xorg-video-ati (1:6.12.192-2ubuntu1) lucid; urgency=low

  * Merge new upstream version from Debian.
    - r6xx/r7xx: fix domain handling in accel code. Improves GetImage
      performace by a factor of ~10. (LP: #544496 ?)
    - radeon: add support for pal on legacy IGP chips (LP: #161893)
    - radeon: disable frac fb div with new pll code
    - Allocate Xv buffers to GTT. This is nice performance boost for Xv
      under KMS.
    - XAA: disable render accel. It's been reported broken for a while.
      (LP: #513956)
    - radeon: avoid using DRI1 init path on DRI2 driver. Improves behavior
      with multi-seat
    - kms: fix ums naming compat for DisplayPort
  * Remaining changes:
    - Add quilt to Build-Depends and call patch/unpatch target.
    - 100_radeon-6.9.0-bgnr-enable.patch: Turn on option to allow xserver to
      skip drawing the root background window for the radeon driver. This
      will make the boot up sequence smoother by eliminating one flicker.
  * Drop 101_support_hd4290.patch - included upstream
 -- Bryce Harrington <email address hidden> Tue, 30 Mar 2010 19:24:28 -0700

Changed in xserver-xorg-video-ati (Ubuntu):
status: Triaged → Fix Released
Matej Kenda (matejken) wrote :

Bryce, thank you.

The desktop flies again!

I tried all combinations: kms/no kms and compiz/no compiz.

New version of the driver performs well in all situations.

Last tried to test performance status on 3/23, but #27284 caused me to cancel testing until it was fixed.

Today I saw that the fix had arrived for "radeon," and that the latest DRM work was accepted into the kernel. I am currently running:

linux: 2.6.34-rc3-git+100401.42be79e
libdrm: 2.4.18-2+git100315.a88e94d
mesa: 7.9-devel+git100310.40adcd6
xf86-video-ati: 6.12.192+git100401.476a1c6

Performance on many applications has actually improved significantly since 6.12.192 was released in mid-March. The vline feature still caps the framerate of 'torcs' at 30 fps most of the time, sometimes slipping into the low 20's, but the playability of the game is no longer as seriously affected as it was when I first opened this bug report in February.

Vline itself works great and no cutting of frames occurs, though I still keep a local git branch with vline removed so I can compare versions of the driver with and without it.

Matej Kenda (matejken) wrote :

Bryce, the desktop became again unbearably slow with Lucid Beta 2.

The version of the xserver-xorg-video-ati is 1:6.12.192-2ubuntu2.

I reinstalled the laptop clean with Beta 2 installation CD. The situation didn't improve.

Matej Kenda (matejken) wrote :

After upgrading more packages, everything works fine again. Please ignore my previous comment.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Fix Released → Confirmed
43 comments hidden view all 123 comments

(In reply to comment #20)
> (In reply to comment #18)
> > To use vblank_mode for dri2 in .drirc you need a seperate dri2 driver with
> > vblank_mode specified, driconf doesn't handle it right.
> >
>
> Great! Is there a bug open for driconf so this can be configured correctly?

I believe I've run into the same problem with my RV770 (running mesa/libdrm/xf86-video-ati, tried both classic and gallium) from git master, where initially in every OpenGL app my framerate seemed to be capped to my screen's refresh (by default - even without a .drirc).

After making this change in my .drirc, the framerate is not capped anymore but it will still be swapping buffers during a retrace, and so I still get multiples of 60Hz (my screens refresh rate). This means in glxgears I get a ridicilous framerate like 2400, but in actual games like ioquake3, I get a framerate that jumps wildly from 30 to 60 to 120Hz, which I find really awkward :/

Is there any way currently to just make it swap buffers without regard for my screens vertical retrace? I realise that means I get a lot of tearing but I'd rather have that than a frame rate jumping around like that.

(In reply to comment #21)

> Is there any way currently to just make it swap buffers without regard for my
> screens vertical retrace? I realise that means I get a lot of tearing but I'd
> rather have that than a frame rate jumping around like that.

For your chip you have to patch xf86-video-ati + disable as above. I'll attach the patch which someone posted in another bug when I find it.

I think this is going to come up again and again, so I hope in the absence of any way to change it on the fly, that it does get made into an xorg.conf option as suggested in comment 17.

Created an attachment (id=37895)
turn off wait for vline for r600+ ddx patch

I compared how Intel (i965) compares when it comes to DRI2 and vsync, and as far as I can tell they have the same problems (needs a special driver="dri2" stansa in drirc, toggling vsync inside a game doesn't work).

This bug can proabably be closed as resolved for radeon, and bugs for the shortcomings mentioned above filed against DRI2.

Situation here: Clean install of 10.04 Lucid Lynx with a current kernel of:

2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010 x86_64

"lspci | grep VGA"

reports a

01:00.0 VGA compatible controller: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO]

The setting of

GRUB_CMDLINE_LINUX="radeon.modeset=0"

in /etc/default/grub resolves the performance issues discussed here for me but xrandr reports a max. screen resolution of 1280x1024 which is nothing compared to the

   2048x1536 80.0* 75.0 75.0 60.0

at which X is running with KMS enabled right now. The proprietary fglrx shipped with Lucid also had some issues regarding performance (resizing windows) as well as screen resolution ("unable to read edid information").

*** Bug 26599 has been marked as a duplicate of this bug. ***

Chris Halse Rogers (raof) wrote :

We've got the new radeon drivers, both kernel and userspace in Maverick, and they have a bunch of performance work done on them. It would be good if someone could try out a LiveCD and check whether this still occurs for them.

Onkar Shinde (onkarshinde) wrote :

Here is my brief testing report with Maverick alpha 3 live CD.

Maverick Alpha 3 Live CD, Radeon 7000- 32M VRAM, 512M RAM.

With KMS
1. General performance improved than Lucid.
2. Video playback using totem
ximagesink - poor framerate, same as lucid
xvimagesink - good quality and framerate, same as Lucid.
3. Games
Osmos game (hemispheregames.com) - Playable, better than Lucid considering that it is live environment.

Without KMS
1. General performance good, same as Lucid.
2. Video playback using totem
ximagesink - poor framerate, same as lucid
xvimagesink - good quality and framerate, same as Lucid.
3. Games
Osmos game (hemispheregames.com) - No video corruption (better than lucid) but not playable.

Scott Talbert (swt-techie) wrote :

For me, with the Maverick Alpha 3 live CD, things seem to be about the same, if not worse.

The numbers below are measured with glxgears.
Lucid w/ KMS: ~2500 frames in 5 seconds.
Lucid w/o KMS: ~5500 frames in 5 seconds.
Maverick w/ KMS: ~300 frames in 5 seconds.
Maverick w/o KMS: ~5500 frames in 5 seconds.

01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Mobility Radeon X300]

Matej Kenda (matejken) wrote :

Things are getting even worse on Maverick on Compaq Evo N1015v.

Maverick w/o KMS: ~1100 frames in 5 seconds, content of window visible on the desktop after the window moved
Maverick w/ KMS: glxgears doesn't work (black window)

Maverick w/ KMS: Compositing doesn't work properly: only background image is visible, no menus, icons
Maverick w/o KMS: Compositing doesn't work properly: background not shown at all, slow

01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility U1 [1002:4336]
     Subsystem: Compaq Computer Corporation Device [0e11:00b0]

description: updated
Matej Kenda (matejken) wrote :

Remote bug closed as duplicate, updated.

Changed in xserver-xorg-driver-ati:
status: Confirmed → Unknown

Installed a ppa kernel 2.6.35-18 yesterday by installing this kernel according to:
root@sofa:/etc/apt/sources.list.d# cat kernel-ppa-ppa-lucid.list
deb http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu lucid main

Key management is still lacking - but this is currently not my concern.

Upgraded to a 2.6.35-19 today while doing a safe-upgrade and running this kernel for about four hours:

uname -a
Linux sofa 2.6.35-19-generic #25~lucid1-Ubuntu SMP Wed Aug 25 03:50:05 UTC 2010 x86_64 GNU/Linux

Had to set:

GRUB_CMDLINE_LINUX="nomodeset"

in /etc/default/grub to get EDID-Scan back to work.

Both 2.6.35 versions showed a quite a bit of a performance increase. The about five to ten seconds delays where no screen updates took place shrank to 0.5 to at most 2 seconds durations.

On top of that the GPU-crashes which were documented in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/585986 did not occur on those kernel versions.

Compared to the stock kernel 2.6.32 I'm pleased with the 2.6.35 now, although the overall performance is quite below the fglrx on Debian Lenny on the same hardware. Fglrx had its own issues not to be discussed here.

Matej: Would you mind to set the duplicate issue number here to get me back on the track, please?

Sorry - my mistake: The GPU-Lockups were documented in

https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/568605

ofc. The ticket above is a similar issue discussed here.

Matej Kenda (matejken) wrote :

Thomas, remote watch bug http://bugs.freedesktop.org/show_bug.cgi?id=26599 was closed as a duplicate of http://bugs.freedesktop.org/show_bug.cgi?id=28771.

I updated the remote watch to reflect that. Is that OK or should the original be left there?

Unfortunately I created an unnecessary Debian remote watch that should be removed.

Tpugliese (thomas-pugliese) wrote :

When booting the Maverick Live CD, it does not even make it to a working X desktop. I can switch to a text console though. This bug is documented here: https://bugs.launchpad.net/bugs/626932

Changed in debian:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in xserver-xorg-driver-ati:
importance: Unknown → Medium
status: Unknown → Confirmed
14 comments hidden view all 123 comments

Does anyone work on this to make it work without patching code to disable completely vsync?

Excuse me, it's just interesting for me.

Why vsync is enabled for all OSS drivers by default?

14 comments hidden view all 123 comments
Tpugliese (thomas-pugliese) wrote :

The Maverick RC live CD shows much improved performance on my setup.

15 comments hidden view all 123 comments

I want to know if are there any developers which would consider it as a bug to get fixed.
It is a real problem for games, mostly for older hardware.
Just try to play any first person shooter game where the framerate jumps from 60 to 30 so quickly.

Is there a similar bug filed for Intel driver?

At least in RedHat's bugzilla there's a relevant patch: https://bugzilla.redhat.com/show_bug.cgi?id=634200

15 comments hidden view all 123 comments
Antonio Flores (antonio-fx) wrote :

Severe slowdown in X acceleration and 3D crashes when trying to change viewing angles in Blender or similar apps are still abundant in final and recently updated Maverick Meerkat versions. Video card used is an ATI Radeon 8500LE that's supposed to be listed as the R200 chipset, but shows up as R100 in the log files.

Situation on Maverick is the same in Lucid, but I had to add Xorg-crackers repository, because opengl apps crashed in fullscreen. My FPS in openarena is 28-40 FPS and in compiz is 42 FPS. Openarena is playable but some games are too slow to play, when KMS is enabled, but when KMS is disabled Xserver is very unstable. Just for comparison, when I disable KMS I get 70+ FPS in compiz.

-------------------
lspci --vv

1:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)
 Subsystem: Micro-Star International Co., Ltd. Device 9995
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 32 (2000ns min), Cache Line Size: 32 bytes
 Region 0: Memory at c8000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at dfee0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

-------------------

Version of mesa:

OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 (RV280 5960) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2
OpenGL version string: 1.3 Mesa 7.10-devel

Scott Talbert (swt-techie) wrote :

In Maverick (with KMS enabled), the main performance issue I still experience is slow scrolling in Firefox (especially when viewing pages like slashdot.org and yahoo.com). I found recently that if I disable EXA pixmaps (Option "EXAPixmaps" "off" in xorg.conf), my scrolling performance improves greatly.

Matej Kenda (matejken) wrote :

Scott, I can confirm that setting EXAPixmaps to off helps.

I my case, not only the speed but also correctness of the display is improved.

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1

Matej Kenda (matejken) wrote :

The card uses 64 MB of RAM. It doesn't have dedicated memory, but uses main RAM (configured in BIOS).

RADEON(0): Chipset: "ATI Radeon IGP320M (U1) 4336" (ChipID = 0x4336)

Scott Talbert (swt-techie) wrote :

My card uses 64MB of RAM also. The driver disables EXA pixmaps if the video RAM is 32MB or less. I'm wondering if this should be changed to 64MB or possibly more. Can anyone else confirm whether or not disabling EXA pixmaps helps their performance?

Changed in debian:
importance: Medium → Unknown
Changed in xserver-xorg-driver-ati:
importance: Medium → Unknown
Changed in debian:
importance: Unknown → Medium
Changed in xserver-xorg-driver-ati:
importance: Unknown → Medium
10 comments hidden view all 123 comments

(In reply to comment #29)
> Is there a similar bug filed for Intel driver?
>
> At least in RedHat's bugzilla there's a relevant patch:
> https://bugzilla.redhat.com/show_bug.cgi?id=634200

I don't see any patches there. Is it perhaps hiding in the .srpm?

vline waits for non-pageflipped swap buffers can be disabled in both radeon and intel with:
Option "SwapbuffersWait" "False"
in the device section of your xorg.conf

The need to manually configure drirc to use driver=dri2 is filed as bug 34401.

I'm still not sure if toggling vsync on/off inside an application is supposed to work (it doesn't seem to with r300g in Sauerbraten or M.A.R.S. for example). What component should a bug be filed against in this case?

At least M.A.R.S. seems to be using glXSwapIntervalSGI for vsync.

(In reply to comment #32)
> I'm still not sure if toggling vsync on/off inside an application is supposed
> to work (it doesn't seem to with r300g in Sauerbraten or M.A.R.S. for example).
> What component should a bug be filed against in this case?
>
> At least M.A.R.S. seems to be using glXSwapIntervalSGI for vsync.

Actually, forget about this part. It works, at least in MARS. Not sure about Sauerbraten, but it could be a bug in the game.

12 comments hidden view all 123 comments
madbiologist (me-again) wrote :

I recall reading recently that 32MB video RAM limit was increased to 64MB. I cant remember what kernel version it first appeared in though.

Regrading the DRI2 page flipping support mentioned in the bug description and comment #3, this was included in the recently released 2.6.38 kernel. You will also need version 6.14.0 of the xserver-xorg-video-ati driver. Both of these packages are included in the upcoming Ubuntu 11.04 "Natty Narwhal" release.

Is anyone able to download the current Natty beta and test?

Matej Kenda (matejken) wrote :

I upgraded the laptop for which this problem was originally reported to Natty Beta.

The situation is not better.

Unity desktop doesn't run on this computer.

madbiologist (me-again) wrote :

G'day Matej. Thanks for testing. I am sorry to hear that Unity doesn't run on that computer, however that is a new and different bug. Are you able to select the classic desktop when booting Natty so that you can test this bug?

Meanwhile, you will be pleased to know the the Ubuntu developers are currently considering postponing the use of Unity and releasing Natty with the classic GNOME desktop - see http://www.phoronix.com/scan.php?page=news_item&px=OTMwMg and http://www.phoronix.com/scan.php?page=news_item&px=OTMwMw

Matej Kenda (matejken) wrote :

Classic desktop is enabled automatically if Unity can't run. I am able to run the computer and there is not much difference from Maverick as far as this issue is concerned.

Matej Kenda (matejken) wrote :

I ran compiz-check script on 11.04 and it reports that the laptop is using vesa driver instead of radeon. Strange.

$ ./compiz-check

Gathering information about your system...

 Distribution: Ubuntu 11.04
 Desktop environment: GNOME
 Graphics chip: ATI Technologies Inc Radeon Mobility U1
 Driver in use: vesa
 Rendering method: AIGLX

Checking if it's possible to run Compiz on your system... [SKIP]

 Checking for hardware/setup problems... [SKIP]

At least one check had to be skipped:
 Error: vesa driver in use

Would you like to know more? (Y/n) Y

 The vesa driver is not capable of running Compiz, you need to install
 the proper driver for your graphics card.

Check if there's an alternate (proprietary) driver available? (Y/n) n

Bryce Harrington (bryce) on 2011-04-30
Changed in xserver-xorg-video-ati (Ubuntu):
importance: Critical → High
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-ati (Ubuntu Maverick):
status: New → Confirmed
Michael Murphy (mmstick) on 2013-11-15
Changed in xserver-xorg-video-ati (Ubuntu Maverick):
status: Confirmed → Fix Committed
Changed in xserver-xorg-video-ati (Ubuntu):
status: Confirmed → Fix Committed
8 comments hidden view all 123 comments
Michel-Ekimia (michel.ekimia) wrote :

@ Michael Murphy : can you explain when and where was the fix commited ?

Matej Kenda, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-ati REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

no longer affects: xserver-xorg-video-ati (Ubuntu Maverick)
Changed in xserver-xorg-video-ati (Ubuntu):
importance: High → Low
status: Fix Committed → Incomplete

The classic r300 driver has been abandoned long ago.
It was replaced by the Gallium driver r300g.

If you have issues with r300g please file a new bug report with component Drivers/Gallium/r300

Thanks.

Changed in debian:
status: Confirmed → Won't Fix
Changed in xserver-xorg-driver-ati:
status: Confirmed → Won't Fix
Displaying first 40 and last 40 comments. View all 123 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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