[RS100] desktop became slow after upgrading to Lucid

[Matej Kenda]

[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]

[Dawitbro (dawitbro)]

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

[agd5f (agd5f)]

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.

[Michel Dänzer (michel-daenzer)]

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.

[Dawitbro (dawitbro)]

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.

[agd5f (agd5f)]

(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.

[Dawitbro (dawitbro)]

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.

[Matej Kenda (matejken)]

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)]

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.

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

apport information

[Matej Kenda (matejken)]

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

[Marián Bača (majoobaca-deactivatedaccount)]

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)]

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)]

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.

[Launchpad Janitor (janitor)]

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

[Matej Kenda (matejken)]

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.

[Dawitbro (dawitbro)]

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)]

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)]

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

[razor7 (ghiamar)]

Hi...iḿ getting the exact same ug in 10.04 LTS, downloaded today! (ATi 4890 no privative drivers)

Be advised!

[razor7 (ghiamar)]

Hi agan, i'm attaching the .xsession-errors log file

[razor7 (ghiamar)]

Hi...installed the latest ATi drivers from ATi, and the error persists, i have auto-login enabled.

HINT: If i restart the xserver (ctrl+alt+backspace) the server restarts as expected, then after typing my username and password, the desktop appears really fast (as it must be)

Best regards!

[razor7 (ghiamar)]

Hi...i have taken a screenshot, because sometimes it even replaces the Ambiance theme with GNOME default. It fixes by starting "System->Preferences->Appearence"

[razor7 (ghiamar)]

Wow...this is really confusing...

I have two similar desktops at home.

1º Desktop specs (Desktop "A"):
    Ubuntu 10.04 LTS
    ASUS P5QC
    Intel Core2Quad Q8200
    2x1GB SuperTalent W1333UA1G8 memory module (2GB Ram Total)
    Sapphire ATi HD4890 1GB DDR5
    Driver Packaging Version 8.723.1-100408a-098580C-ATI
    2D Driver Version 8.72.11

2º Desktop specs (Desktop "B"):
    Ubuntu 10.04 LTS
    ASUS P5QC
    Intel Core2Quad Q8400
    2x2GB OCZ OCZ3G13332G memory module (4GB Ram Total)
    Sapphire ATi HD4890 1GB DDR5
    Driver Packaging Version 8.723.1-100408a-098580C-ATI
    2D Driver Version 8.72.11

Both machines installed from scratch, so both root partitions where formatted at install time. Both with same ATi propietary driver.

The funny thing is that "Desktop A" boots up as expected, really short delay between boot menu and usable GNOME Desktop. In "Desktop B" boot thime is unnacceptable (60 secs at least), Skype and Empathy login sounds being played, but only mouse pointer with blask background is displayed!

Please also take a look at my previous screenshot, because sometimes is unable to load the default GNOME theme.

Please advise...this is really weird!

[razor7 (ghiamar)]

Forgot to mention... Ubuntu 10.04 AMD x64 LTS

[razor7 (ghiamar)]

Just in case, my two Desktops bootchart images

[Onkar Shinde (onkarshinde)]

@razor7,

You are using very new ATI card. This bug is about performance regression on very old cards. Please file a separate bug for your problem.

[Onkar Shinde (onkarshinde)]

Unfortunately I see this problem on a fresh install of Lucid with card Radeon 7000. The video playback using totem is very slow (irrespective of codec). Also UI is very slow. The problem is fixed by disabling kms using radeon.modeset=0 while booting.

Should I file a separate bug for this?

[Onkar Shinde (onkarshinde)]

I see the performance problem in normal GUI as well as video playback on a fresh install of Lucid with card Radeon 7000. Turning off KMS makes the performance issue go away.
Let me know what other details you need.

[Onkar Shinde (onkarshinde)]

I tested two kernels from mainline PPA, 2.6.33-3 and 2.6.34-rc6. With KMS enabled the UI performance is really good on these kernels. Video playback is better (faster) but not normal.

[razor7 (ghiamar)]

Hi...i have changed the specs of Destop B
2º Desktop specs (Desktop "B"):
    Ubuntu 10.04 LTS
    Gigabyte H55M-USB3
    Intel Core i7 860
    2x2GB OCZ OCZ3G13332G memory module (4GB Ram Total)
    Sapphire ATi HD4890 1GB DDR5
    Driver Packaging Version 8.723.1-100408a-098580C-ATI
    2D Driver Version 8.72.11

The behaiviour is the same...allways is a 10 or 15 secs delay before full desktop shows up. Sometimes, no even load default desktop theme, falling into GNOME default theme!

This is tested on fresh iinstall after mother-processor upgrade.

Be advised

[razor7 (ghiamar)]

Hello...I cant believe my eyes!...In my configuration. I had Floppy Enabled on BIOS, but no floppy present at all...Disabling Floppy from BIOS made the issue go away, now, both Desktops work the same way...no delay in GNOME boot...

De advised, it maybe the solution for this...

Best regards!

[Shaw (svrana)]

I see the performance regression with the rv280 (Radeon 9200 PRO) graphics card. Disabling KMS does work around the problem, with the odd drawback that the text on drop-down menus for the non-QT apps I use in KDE (i.e., File/Edit/View in Firefox or Buddies, Accounts, Tools in pidgin, for example) do not render properly, making the apps hard to use. With KMS enabled at boot, I do not have any boot display problems other than the performance regression. Disabling compiz without also disabling Kernel Mode Setting does not work around the 2D aspects of the performance problem for me.

[signalfrax (signalfrax)]

This bug affects NVIDIA as well.

[Antonio Navarro (anavarrog)]

Kernel 2.6.34 installation worked on Radeon Xpress 200M. No more black screens. After disabling composition i can play videos on fullscreen at normal speed. With composition enabled, fullscreen playback is slower

[Scott Talbert (swt-techie)]

After upgrading to Lucid, video performance was noticeably slower (for example, when paging up and down in Firefox when viewing slashdot.org, there was noticeable lag). This is with compiz disabled. When I run with radeon.modeset=0, performance seems to be normal. I am wondering if I am experiencing the same bug as the original poster. My video card:

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

[kiu (kiu)]

setting radeon.modeset=0 on my IBM Thinkpad R40 reduced the load a lot, the desktop feels much better now.
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]

[Sven Arvidsson (sa)]

With kernel 2.6.35, there doesn't seem to be a way to turn off vsync/vblank.

E.g. "vblank_mode=0 glxgears" has no effect.

This seems to be the same for both r300c and r300g.

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: RV570
-- Model: Asus EAX1950Pro 256MB
-- Display connector: DVI

-- xf86-video-ati: 801e83227a59a29eea425ea612083bbf2b536c30
-- xserver: 1.8.1.901
-- mesa: a5c44986a3f19936df448fe4ae47ca77ece9b0ce
-- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df
-- kernel: 2.6.35-rc3

[thewk (theewk)]

I can confirm these performance issues, I have exactly the card as original poster:

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

Just did upgrade from 9.10. My laptop is Compaq Evo N1015v.
However with 9.10 I had problems with booting as it always hang on black sreen and started only when I booted in recovery and then after logging in started gdm by typing sudo start gdm. By default compiz effects were enabled which caused artifacts. 10.04 does not have any of those problems, but the performance is bad.

[Jesse Barnes (jbarnes-virtuousgeek)]

You need both:

commit 234286c0f8b7d30ed49223c648d4c73c1a517ab3
Author: Jesse Barnes <email address hidden>
Date: Thu Apr 22 12:47:41 2010 -0700

    DRI2: add config query extension

and

commit 45e2b51c853471b79004a954ce3092a253b20b77
Author: Jesse Barnes <email address hidden>
Date: Thu Apr 22 12:49:03 2010 -0700

    DRI2/GLX: check for vblank_mode in DRI2 GLX code

for vblank_mode to work. Does your Mesa build have those?

[Sven Arvidsson (sa)]

Yes, I'm using git master, so they're both there.

[Jesse Barnes (jbarnes-virtuousgeek)]

Oh, for the DRI2 radeon driver you'll probably need to add an explicit option somewhere; maybe the code path that used to check the vblank_mode flags is no longer called.

See intel_screen.c:
...
DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_ALWAYS_SYNC)
...

there's probably a similar section in the radeon driver somewhere. You'll also need to add support for the new DRI2 config extension to the driver, again see intel_screen.c's intelScreenExtensions array:
...
    &dri2ConfigQueryExtension.base,
...

Hope that helps.

[agd5f (agd5f)]

Should be fixed in:
0a7803cbaca13033d9ed31ef33f59efa913fbfce

[Sven Arvidsson (sa)]

Created an attachment (id=37084)
dri2 vblank for gallium

(In reply to comment #4)
> Should be fixed in:
> 0a7803cbaca13033d9ed31ef33f59efa913fbfce

Thanks, it works with the classic r300 driver now.

For the Gallium one I had to make the same change in the dri state tracker. Not sure if it's the correct fix, but it works here.

[Sven Arvidsson (sa)]

Hmm, I still can't toggle vsync on/off inside games, it has no effect, but maybe that's a separate bug?

[Lists-andyfurniss (lists-andyfurniss)]

(In reply to comment #4)
> Should be fixed in:
> 0a7803cbaca13033d9ed31ef33f59efa913fbfce

For me using rv670 it doesn't work from .drirc eg.

<driconf>
    <device screen="0" driver="r600">
        <application name="all">
            <option name="force_s3tc_enable" value="false" />
            <option name="disable_s3tc" value="true" />
            <option name="vblank_mode" value="0"/>
        </application>
    </device>
</driconf>

It does work as an env so vblank_mode=0 ./gears works - but I still get wait for vline sync which means that fullscreen games or gears maximised gets capped to refresh.

[Sven Arvidsson (sa)]

I can confirm that setting vblank_mode=0 in drirc doesn't work here either.

Can't reproduce the other problem though, window or fullscreen doesn't make a difference.

[Lists-andyfurniss (lists-andyfurniss)]

(In reply to comment #8)
> I can confirm that setting vblank_mode=0 in drirc doesn't work here either.
>
> Can't reproduce the other problem though, window or fullscreen doesn't make a
> difference.

Maybe the wait for vline type vsync I get is r600 specific.

[Toni Spets (hifi)]

(In reply to comment #9)
> (In reply to comment #8)
> > I can confirm that setting vblank_mode=0 in drirc doesn't work here either.
> >
> > Can't reproduce the other problem though, window or fullscreen doesn't make a
> > difference.
>
> Maybe the wait for vline type vsync I get is r600 specific.

I can also confirm .drirc gets ignored but env vblank_mode works.

To disable vsync completely you currently (and before) need a DDX hack along with vblank_mode=0.

With this patch interestingly glxgears goes from ~1400 fps to ~2100 fps and Quake 2 can run uncapped.

What is the real solution and why is this patch needed in DDX?

From 311d4c299ed8de4f28d3fd637a7bde8176db245b Mon Sep 17 00:00:00 2001
From: Toni Spets <email address hidden>
Date: Wed, 17 Feb 2010 17:37:49 +0200
Subject: [PATCH] Disable vsync

---
 src/radeon_dri2.c | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index a0ed085..b74a18b 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -315,7 +315,7 @@ radeon_dri2_copy_region(DrawablePtr drawable,
     }

     vsync = info->accel_state->vsync;
- info->accel_state->vsync = TRUE;
+ info->accel_state->vsync = FALSE;

     (*gc->ops->CopyArea)(src_drawable, dst_drawable, gc,
                          0, 0, drawable->width, drawable->height, 0, 0);
--
1.7.1

[agd5f (agd5f)]

(In reply to comment #10)
>
> What is the real solution and why is this patch needed in DDX?

The real solution to what? The various GLX vsync/vblank extensions basically just expose frame counters and vertical retrace events to applications so they can use them for synchronization. They have nothing to do with tearing prevention directly. The code in the ddx you are asking about has nothing to do with the GLX vsync/vblank extensions; it is there to prevent tearing on GL buffer swaps. The variable should probably have been called vline_wait rather than vsync. What the code does is forces the GPU to wait until the current scanline is past the area that will be updated by the swap before doing the swap blit. It's the same method used by Xv to prevent tearing when rendering to the front buffer.

[Lists-andyfurniss (lists-andyfurniss)]

(In reply to comment #10)

> With this patch interestingly glxgears goes from ~1400 fps to ~2100 fps and
> Quake 2 can run uncapped.

Thanks for the patch. The gears difference is expected as the wait for vline vsync still stalls GPU for the lines that the gears window covers. Changing res would also give different fps as more/less of the screen was outside the window.

[Lists-andyfurniss (lists-andyfurniss)]

(In reply to comment #11)
> (In reply to comment #10)
> >
> > What is the real solution and why is this patch needed in DDX?
>
> The real solution to what? The various GLX vsync/vblank extensions basically
> just expose frame counters and vertical retrace events to applications so they
> can use them for synchronization.

I guess what people want is a way to turn it off without patching, games don't seem to be able to.

Personally I am not that bothered about tearing in FPS type games and my old PC is often not able to render at refresh rate anyway - which means without triple buffering vsync hurts my already low framerate.

> It's the same method used by Xv to prevent tearing when rendering
> to the front buffer.

Can GL have a switch like XV has - or should games in theory be able to turn off, but are prevented by a bug?

Digression - I notice that XV with vsync on can't live with frame rate = refresh rate, which I sometimes use for "proper" deinterlaced TV. GL vsync is fine and GL wait vline is much better that XV. Is this a driver issue or is it just that mplayers gl driver makes mplayer behave differently to it's xv driver?

[Toni Spets (hifi)]

(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #10)
> > >
> > > What is the real solution and why is this patch needed in DDX?
> >
> > The real solution to what? The various GLX vsync/vblank extensions basically
> > just expose frame counters and vertical retrace events to applications so they
> > can use them for synchronization.
>
> I guess what people want is a way to turn it off without patching, games don't
> seem to be able to.
>
> Personally I am not that bothered about tearing in FPS type games and my old PC
> is often not able to render at refresh rate anyway - which means without triple
> buffering vsync hurts my already low framerate.
>

Yes, this is exactly what I'm talking about.

Quake-style games have options like gl_swapinterval and gl_ext_swapinterval but they do not seem to do anything. Honestly I don't even know what they should do, but on other platforms they used to disable vsync on some cards.

> > The code in the ddx you are asking about has nothing to
> > do with the GLX vsync/vblank extensions; it is there to prevent tearing on
> > GL buffer swaps.

And it hurts performance not being able to turn it off without a patch. I like tearing! ;-)

Btw. are we still on-topic on this bug when the actual fix for vblank_mode was already committed?

[Sven Arvidsson (sa)]

(In reply to comment #14)
>
> Btw. are we still on-topic on this bug when the actual fix for vblank_mode was
> already committed?

There's still three issues here:

1, The Gallium driver, not sure if the change I did is in the correct place?
2, drirc being ignored, perhaps this isn't specific to radeon?
3, Toggling vsync on/off from an application. Again, perhaps a separate issue?

[Sven Arvidsson (sa)]

(In reply to comment #15)
> There's still three issues here:
>
> 1, The Gallium driver, not sure if the change I did is in the correct place?

Nevermind about this one, I should have remembered to do a git pull before commenting here :)

[agd5f (agd5f)]

(In reply to comment #13)
> Can GL have a switch like XV has - or should games in theory be able to turn
> off, but are prevented by a bug?

I'm not sure how you'd expose it. You could make it a driver option, but then you'd have to restart X to change it. There's no GLX extension to cover tearing as far as I know.

>
> Digression - I notice that XV with vsync on can't live with frame rate =
> refresh rate, which I sometimes use for "proper" deinterlaced TV. GL vsync is
> fine and GL wait vline is much better that XV. Is this a driver issue or is it
> just that mplayers gl driver makes mplayer behave differently to it's xv
> driver?

Xv in general does not provide any mechanism for application synchronization. I.e., here's no vblank events provided by Xv for app synchronization. That's what the GLX vsync extensions do.

The driver uses the vline wait for avoid tearing for both Xv and GL buffer swaps, they have nothing to do with the GLX vsync extensions. Those extensions only provide events that the application can use for synchronization. If you remove the vline wait code, you can still synchronize your application to the refresh rate, but you might still get tearing depending when the GL buffer swap happens.

[Robert Hooker (sarvatt)]

(In reply to comment #7)
> (In reply to comment #4)
> > Should be fixed in:
> > 0a7803cbaca13033d9ed31ef33f59efa913fbfce
>
> For me using rv670 it doesn't work from .drirc eg.
>
> <driconf>
> <device screen="0" driver="r600">
> <application name="all">
> <option name="force_s3tc_enable" value="false" />
> <option name="disable_s3tc" value="true" />
> <option name="vblank_mode" value="0"/>
> </application>
> </device>
> </driconf>
>
> It does work as an env so vblank_mode=0 ./gears works - but I still get wait
> for vline sync which means that fullscreen games or gears maximised gets capped
> to refresh.

To use vblank_mode for dri2 in .drirc you need a seperate dri2 driver with vblank_mode specified, driconf doesn't handle it right.

Using your example it'd be:

<driconf>
    <device screen="0" driver="dri2">
        <application name="Default">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
   <device screen="0" driver="r600">
       <application name="all">
           <option name="force_s3tc_enable" value="false" />
           <option name="disable_s3tc" value="true" />
       </application>
   </device>
</driconf>

[Lists-andyfurniss (lists-andyfurniss)]

(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.
>
> Using your example it'd be:
>
> <driconf>
> <device screen="0" driver="dri2">
> <application name="Default">
> <option name="vblank_mode" value="0" />
> </application>
> </device>
> <device screen="0" driver="r600">
> <application name="all">
> <option name="force_s3tc_enable" value="false" />
> <option name="disable_s3tc" value="true" />
> </application>
> </device>
> </driconf>

Thank you, that does the trick.

[Sven Arvidsson (sa)]

(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?

[lcn_mustard (lcn-mustard)]

This bug affects NVIDIA as well.

[Hans Nieser (hnsr)]

(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.

[Lists-andyfurniss (lists-andyfurniss)]

(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.

[Lists-andyfurniss (lists-andyfurniss)]

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

[Sven Arvidsson (sa)]

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.

[Thomas Antepoth (ta-ubuntu-antepoth)]

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").

[agd5f (agd5f)]

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

[Chris Halse Rogers (raof)]

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)]

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)]

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)]

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]

[Matej Kenda (matejken)]

Remote bug closed as duplicate, updated.

[Thomas Antepoth (ta-ubuntu-antepoth)]

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?

[Thomas Antepoth (ta-ubuntu-antepoth)]

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)]

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)]

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

[Tomasz Czapiewski (xeros)]

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

[Nikolay Rysev (mad-f3ka)]

Excuse me, it's just interesting for me.

Why vsync is enabled for all OSS drivers by default?

[Tpugliese (thomas-pugliese)]

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

[Tomasz Czapiewski (xeros)]

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.

[T-artem (t-artem)]

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

[Antonio Flores (antonio-fx)]

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.

[Marián Bača (majoobaca-deactivatedaccount)]

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)]

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)]

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

[Scott Talbert (swt-techie)]

Matej,

How much video RAM does your card have?

[Matej Kenda (matejken)]

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)]

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?

[Idr (idr)]

(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?

[agd5f (agd5f)]

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

[Sven Arvidsson (sa)]

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.

[Sven Arvidsson (sa)]

(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.

[madbiologist (me-again)]

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)]

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)]

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)]

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)]

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

[Launchpad Janitor (janitor)]

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

[Michel-Ekimia (michel.ekimia)]

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

[penalvch (penalvch)]

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

[Andreas-boll-dev (andreas-boll-dev)]

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.

[Johannes Satter (johannessatter)]

You are right brooo https://crackshit.com/