[R580] EXA has severe performance impact on ATI R580 (X1900)

Bug #315889 reported by Alexander Sack on 2009-01-10
4
Affects Status Importance Assigned to Milestone
xserver-xorg-video-ati (Ubuntu)
High
Unassigned
Jaunty
High
Unassigned

Bug Description

Jaunty upgrade 1:6.9.0.91-1ubuntu3 had severe performance impact on my "ati" driver install. The desktop was unusable as even simple operations made CPU peak at 100%.

Option AccelMethod "XAA" brought performance back to where it was before (not so bad).

besides from that option i don't have any option in xorg.conf device section.

Let me know if you need more information.

[lspci]
05:00.0 VGA compatible controller: ATI Technologies Inc R580 [Radeon X1900]
 Subsystem: ATI Technologies Inc Device 0b12
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M]
 Region 2: Memory at fd6f0000 (64-bit, non-prefetchable) [size=64K]
 Region 4: I/O ports at 5c00 [size=256]
 [virtual] Expansion ROM at fd600000 [disabled] [size=128K]
 Capabilities: <access denied>
 Kernel modules: fglrx

05:00.1 Display controller: ATI Technologies Inc Device 7264
 Subsystem: ATI Technologies Inc Device 0b13
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Region 0: Memory at fd6e0000 (64-bit, non-prefetchable) [disabled] [size=64K]
 Capabilities: <access denied>

Alexander Sack (asac) wrote :

critical as default install becomes unusable as it is now;

Solution for me appear to be to nail down the issue and fix it (upstream); or to blacklist this card from using EXA in jaunty.

Changed in xserver-xorg-video-ati:
importance: Undecided → Critical
status: New → Confirmed
Alexander Sack (asac) wrote :

for now, nominating alpha 5 to keep this on radar while giving us some time ;).

Changed in xserver-xorg-video-ati:
milestone: none → jaunty-alpha-5
status: Confirmed → Triaged
Tormod Volden (tormodvolden) wrote :

If you're triaging your own bugs, at least make sure you have attached your Xorg.0.log :)

Changed in xserver-xorg-video-ati:
status: Triaged → Incomplete
Tormod Volden (tormodvolden) wrote :

Unless it is confirmed on many different cards, it's not "Critical" either...

On Sun, Jan 11, 2009 at 12:22:04PM -0000, Tormod Volden wrote:
> If you're triaging your own bugs, at least make sure you have attached
> your Xorg.0.log :)

Oh, indeed I failed. Attaching ...

Anyway, I cannot reproduce anymore. Not sure what fixed; i didnt get
much updates in the meantime that seem related. maybe kernel?

 status invalid

 - Alexander

Alexander Sack (asac) wrote :

On Sun, Jan 11, 2009 at 12:22:04PM -0000, Tormod Volden wrote:
> If you're triaging your own bugs, at least make sure you have attached
> your Xorg.0.log :)

Oh, indeed I failed. Attaching ...

Anyway, I cannot reproduce anymore. Not sure what fixed; i didnt get
much updates in the meantime that seem related. maybe kernel?

 status invalid

 - Alexander

Changed in xserver-xorg-video-ati:
importance: Critical → Medium
milestone: jaunty-alpha-5 → none

damn email interface ... reposting:

On Sun, Jan 11, 2009 at 12:22:04PM -0000, Tormod Volden wrote:
> If you're triaging your own bugs, at least make sure you have attached
> your Xorg.0.log :)

Oh, indeed I failed. Attaching ...

Anyway, I cannot reproduce anymore. Not sure what fixed; i didnt get
much updates in the meantime that seem related. maybe kernel?

 status invalid

 - Alexander

Changed in xserver-xorg-video-ati:
status: Incomplete → Invalid
Alexander Sack (asac) wrote :

reopening ... see it again. Really slow to switch apps and gnome-terminal is also mostly unusable.

Changed in xserver-xorg-video-ati:
status: Invalid → Triaged
Alexander Sack (asac) wrote :
Alberto Milone (albertomilone) wrote :

Does it help if you kill both gnome-settings-daemon and gnome-power-manager?

Tormod Volden (tormodvolden) wrote :

You don't have access to the DRI device. What are the permissions on /dev/dri/card0 ? Are you member of the "video" group?

Changed in xserver-xorg-video-ati:
assignee: nobody → tormodvolden
status: Triaged → Incomplete
Bryce Harrington (bryce) on 2009-02-10
Changed in hal:
assignee: tormodvolden → nobody
importance: Medium → High
milestone: none → ubuntu-9.04-beta
status: Incomplete → Triaged
Alexander Sack (asac) wrote :

this still exists so its not a hal issue. also i am member of video group.

Changed in hal:
importance: High → Medium
milestone: ubuntu-9.04-beta → none
status: Triaged → New
Bryce Harrington (bryce) on 2009-02-10
description: updated
Alexander Sack (asac) wrote :

setting high as its a regression and makes the default desktop unusable on a not so old ati card that previously worked.

Changed in xserver-xorg-video-ati:
importance: Medium → High
Bryce Harrington (bryce) on 2009-02-10
Changed in xserver-xorg-video-ati:
milestone: none → ubuntu-9.04-beta
status: New → Triaged
Tormod Volden (tormodvolden) wrote :

Please attach new logs.

Bryce Harrington (bryce) wrote :

(asac reported the issue went away after purging fglrx.)

asac, let me know if you're seeing any further performance impacts now that this is squared away, or else that we can close this bug.

Changed in xserver-xorg-video-ati:
milestone: ubuntu-9.04-beta → none
Alexander Sack (asac) wrote :

so this happend because i had the linux-source-fglrx package installed. dkms kicked in and the module was loaded and then used by -ati driver ... scary.

I think we need to do something about this on packagin layer ... either -ati should conflict with that package, or linux-source-fglrx could break -ati driver. another option would be to ship a blacklist entry in the -ati package.

All this not perfect, anyone can think of any better solution maybe in X?

Tormod Volden (tormodvolden) wrote :

There used to be a hook in modprobe that would only load the fglrx module if "fglrx" was specified as the driver in xorg.conf. Now that xorg.conf is not used any longer (for ati at least, and I suppose for fglrx neither?), this is no solution. I guess our X has been patched to prefer the fglrx driver if it is installed. One ugly way would then be to only load the fglrx module if fglrx is installed.

Adding a "fglrx breaks ati" would most precisely describe the truth, but it we don't really want people to uninstall ati because they want to try out fglrx.

At least there should be some dependency between linux-source-fglrx and the fglrx package so that uninstalling fglrx will uninstall linux-source-fglrx as well. asac, did you keep the fglrx package and switched to ati in xorg.conf? This scenario should ideally be handled by the above mentioned module hook.

We might need a stronger warning in Restricted Manager to keep people from installing fglrx. Hopefully we can soon stop supporting it, and leave it to ATI to sort this out in their own offering.

On Sun, Feb 15, 2009 at 06:10:48PM -0000, Tormod Volden (~offline till March) wrote:
> There used to be a hook in modprobe that would only load the fglrx
> module if "fglrx" was specified as the driver in xorg.conf. Now that
> xorg.conf is not used any longer (for ati at least, and I suppose for
> fglrx neither?), this is no solution. I guess our X has been patched to
> prefer the fglrx driver if it is installed. One ugly way would then be
> to only load the fglrx module if fglrx is installed.
>

in my case i only had the fglrx "kernel" part installed and not the
xorg part. So this seems to be no solution.

> Adding a "fglrx breaks ati" would most precisely describe the truth, but
> it we don't really want people to uninstall ati because they want to try
> out fglrx.

Well, i am not really for promoting fglrx ... if there is the choice
of a) either breaking your free ati driver or b) making it painful to
test fglrx lets chooose b).

>
> At least there should be some dependency between linux-source-fglrx and
> the fglrx package so that uninstalling fglrx will uninstall linux-
> source-fglrx as well. asac, did you keep the fglrx package and switched
> to ati in xorg.conf? This scenario should ideally be handled by the
> above mentioned module hook.

i didnt keep the xorg fglrx package ... i removed it and forgot about
the linux-source package. AFAIK, there is no mechanism to make
linux-source-fglrx go away if you uninstlal the xorg package; a bit
hacky, but we could put the content of linux-source-fglrx into the
xorg package.

IMO, we should add a hook that doesnt load the fglrx module unless

 a) fglrx is in xorg.conf
 b) not -ati xorg driver is installed

 - Alexander

Alexander Sack (asac) wrote :

On Tue, Feb 17, 2009 at 09:18:18AM -0000, Alexander Sack wrote:
> On Sun, Feb 15, 2009 at 06:10:48PM -0000, Tormod Volden (~offline till March) wrote:
> > There used to be a hook in modprobe that would only load the fglrx
> > module if "fglrx" was specified as the driver in xorg.conf. Now that
> > xorg.conf is not used any longer (for ati at least, and I suppose for
> > fglrx neither?), this is no solution. I guess our X has been patched to
> > prefer the fglrx driver if it is installed. One ugly way would then be
> > to only load the fglrx module if fglrx is installed.
> >
>
> in my case i only had the fglrx "kernel" part installed and not the
> xorg part. So this seems to be no solution.
>
> > Adding a "fglrx breaks ati" would most precisely describe the truth, but
> > it we don't really want people to uninstall ati because they want to try
> > out fglrx.
>
> Well, i am not really for promoting fglrx ... if there is the choice
> of a) either breaking your free ati driver or b) making it painful to
> test fglrx lets chooose b).

Actually, I retract that statement. I think we need to find something
on code level, like below ...

> IMO, we should add a hook that doesnt load the fglrx module unless
>
> a) fglrx is in xorg.conf
> b) not -ati xorg driver is installed
>
> - Alexander
>

 - Alexander

Tormod Volden (tormodvolden) wrote :

> i didnt keep the xorg fglrx package ... i removed it and forgot about
> the linux-source package. AFAIK, there is no mechanism to make
> linux-source-fglrx go away if you uninstlal the xorg package;

What if we let linux-source-fglrx depend on the fglrx ddx?

Bryce Harrington (bryce) wrote :

We have a master bug already open about -fglrx / -ati incompatibilities, bug #285603. I've merged some of the comments from this bug over to that one, so we can close this one and just have a single bug for the incompatibility problems.

Changed in xserver-xorg-video-ati:
status: Triaged → Fix Released
Alexander Sack (asac) wrote :

On Wed, Feb 18, 2009 at 10:21:02PM -0000, Bryce Harrington wrote:
> We have a master bug already open about -fglrx / -ati incompatibilities,
> bug #285603. I've merged some of the comments from this bug over to
> that one, so we can close this one and just have a single bug for the
> incompatibility problems.
>
> ** Changed in: xserver-xorg-video-ati (Ubuntu Jaunty)
> Status: Triaged => Fix Released
>

fix released? you could have marked this one as dupe :).

 - Alexander

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers