[radeon] Falling back on software rendering after update

devyn · 2010-01-15 00:15:36

I just recently updated the kernel and everything. The relevant packages are:

kernel26 2.6.32.3-1
xf86-video-ati 6.12.4-3
xorg-server 1.7.3.902-1

Relevant output from glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.2
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.7
OpenGL shading language version string: 1.20

dmesg | grep drm:

[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.31.0 20080528 for 0000:00:08.0 on minor 0

It would appear to be falling back on the software rasterizer. Everything runs a lot slower, and where glxgears used to get over 600FPS, it is now only getting 60-80FPS.

Please help!

Last edited by devyn (2010-01-15 00:17:26)

drcouzelis · 2010-01-15 00:18:14

Are you using Compiz?

Do you have KMS (really teensy font during boot) enabled?

devyn · 2010-01-15 03:57:17

No, not using Compiz. And before the update I had KMS turned off, but now "lsmod | grep kms" shows:

drm_kms_helper         21971  1 radeon
drm                   126588  3 radeon,ttm,drm_kms_helper

which is odd, because I'm explicitly disabling KMS with radeon.modeset=0… also, with the new kernel, KMS is supposed to be off by default for ATI cards.

So, as you can see, I'm extremely confused. That's why I asked here.

drcouzelis · 2010-01-15 13:00:33

I don't think KMS is involved. I get the same output from "lsmod" as you, and I have KMS disabled.

What Radeon card are you using?

What window manager or desktop environment are you using?

Do you have anything in your "/etc/X/xorg.conf" file? What is it? Consider removing / renaming it.

Do you have a "/usr/share/applications/compiz.desktop" file? Consider temporarily removing / renaming it.

Because there sure has been a lot of talk about Radeon cards, accelerated graphics, and the recent kernel upgrade, have you tried every other suggestion that is found in the Arch Linux forums?

Perry3D · 2010-01-15 17:15:34

drcouzelis wrote:

I don't think KMS is involved. I get the same output from "lsmod" as you, and I have KMS disabled.
What Radeon card are you using?
What window manager or desktop environment are you using?
Do you have anything in your "/etc/X/xorg.conf" file? What is it? Consider removing / renaming it.
Do you have a "/usr/share/applications/compiz.desktop" file? Consider temporarily removing / renaming it.
Because there sure has been a lot of talk about Radeon cards, accelerated graphics, and the recent kernel upgrade, have you tried every other suggestion that is found in the Arch Linux forums?

It doesn't matter what window manager he is using.

@devyn: Open your /var/log/Xorg.0.log and search for errors.

devyn · 2010-01-15 23:59:34

This is quite a crappy card, but it was the best PCI card I could find at the time. It's a Radeon 9250.

And although I do have Compiz installed, I am sure I'm not running it. My desktop env. is a custom blend of openbox3 and a bunch of other stuff.

And it is definitely using the software rasterizer, which is weird; why I say this is because whenever I play music, my graphics slow down (which didn't used to happen) and the output of "glxinfo" shows that the current OpenGL driver is Mesa Software Rasterizer, which would make sense.

The only thing in my Xorg.0.log that looks suspicious is this:

(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/xorg/modules/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0

which did not come up before (I have checked some old logs). In the old logs, all I see is:

(==) AIGLX enabled

My X config looks fine: http://pastie.org/780328

I have absolutely no idea what the hell is going on… please help me???

tomk · 2010-01-16 00:41:04

I reckon you'll find this in your X log:

(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
[dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
[dri] Disabling DRI.

It's in mine, and I have the same problem.
(Top tip: if you have X issues, the first thing you look for in the log is '(EE)' )

Until there's another release of the xorg ati driver, I'd say try the -git build - that's what I'm going to do anyway.

devyn · 2010-01-16 01:10:28

That's not what I have…

(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.

But, I will try the git version.

Edit: the git version gave the same error message.

Last edited by devyn (2010-01-16 01:23:56)

tomk · 2010-01-16 23:36:44

Well.. I tried the git version, and I got a different error message:

(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
[dri] This chipset requires a kernel module version of 1.17.0,
[dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel.
[dri] If using kernel modesetting, make sure your module is
[dri] loaded prior to starting X, and that this driver was built
[dri] with support for KMS.
[dri] Disabling DRI.

So I am using kernel modesetting, and I have made sure that the radeon module is loaded before X starts. BUT.. I couldn't build xf86-video-ati-git with kms support, as per the error message. That is, I couldn't until I rebuilt libdrm with --enable-radeon-experimental-api. Then I got the radeon xorg driver with kms support.....
but still software rendering. New error message:

(EE) AIGLX error: Calling driver entry point failed
(EE) AIGLX: reverting to software rendering

However, X/console switching is instantaneous again (it was laggy), so it's not all bad.

/me heads back to google, understanding a bit more why radeon kms is disabled by default....

devyn · 2010-01-20 04:38:13

Hmm, I'm having a different error than everyone else.

(WW) RADEON(0): Direct rendering is not supported when VGA arb is necessary for the device
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.

Does that help???

Labello · 2010-01-22 13:24:37

hi there

this is my first post and i have got to approve the OPs issue. i get the very same log entries and all 3D-apps fall back on software rendering. still kwin with compositing enabled works very well.
I use the latest version of arch-kernel26,xorg and xf86-video-ati and have got an ATI FireGL5200

apps like blender or games like openarena just use software rendering. moreover teeworls is also having about 1FPS while operating on a very low resolution.

i even tried the *-git drivers from AUR but their performance was even worse.

explicitely disabling KMS did not make it any better.

i recently switched from arch to ubuntu. i was using karmic koala and there i never got any issues i was able to play nexuiz on a pretty good quality. i have always been using the xorg-edgers-repo for git versions of the display drivers and they always worked like a charm.

I got no errors in xorg.0.log just warnings:

(WW) RADEON(0): DRI init changed memory map, adjusting ...
(WW) RADEON(0):   MC_FB_LOCATION  was: 0xbfffb000 is: 0xbfffb000
(WW) RADEON(0):   MC_AGP_LOCATION was: 0x003f0000 is: 0xffffffc0
(WW) RADEON(0): Option "XAANoOffscreenPixmaps" is not used

xorg.conf

Section "Screen"                         
        Identifier      "Configured Screen Device"
        Device  "Configured Video Device"         
        SubSection "Display"                      
                Virtual 2880 1200
        EndSubSection
EndSection

Section "Module"
        Load  "glx"
        Load  "dri"
        Load  "drm"
EndSection

Section "Device"
        Identifier      "Configured Video Device"
        Driver          "ati"
        BusID           "PCI:1:0:0"
        Option          "BusType" "PCI"
        Option          "XAANoOffscreenPixmaps"
        Option "EnablePageFlip" "on"
        Option          "AccelMethod" "EXA"
EndSection

Section "DRI"
        Mode 0666
EndSection

Section "Extensions"
        Option "Composite" "Enable"
EndSection

tomk · 2010-01-23 09:44:02

Update - after 2.6.32.4 kernel upgrade, I decided to turn off kms for a while, but I'm still using xf86-videa-ati-git and libdrm with --enable-radeon-experimental-api. I now have no errors in the X log, and glxinfo says

OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RS400 5955) 20090101  NO-TCL
OpenGL version string: 1.5 Mesa 7.7

Maybe this is of use to someone.

Labello · 2010-01-23 10:02:44

tomk wrote:

I now have no errors in the X log, and glxinfo says
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RS400 5955) 20090101  NO-TCL
OpenGL version string: 1.5 Mesa 7.7
Maybe this is of use to someone.

how can i enable the --enable-radeon-experimental-api?

this would be fancy if it worked as you said.

tomk · 2010-01-23 10:05:55

Rebuild libdrm with that flag, then build xf86-video-ati-git against it.

Labello · 2010-01-23 12:21:40

is there any chance that this experimental api will be in "mainline" in the near future? because this sounds a bit like to much effort for me. but i will try anyway. maybe it works for me too. thanks in advance!

EDIT: I did compile libdrm-git with the mentioned flag and built xf86-video-ati-git and I still got software rasterizer enabled.

Last edited by Labello (2010-01-23 13:22:04)

devyn · 2010-01-24 23:15:00

I did everything tomk said and I still have (from glxinfo):

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.7

And in my Xorg.0.log:

(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.

If it makes any difference, I have an R200 card.

Labello · 2010-01-29 17:22:34

well i finally got it working. i first uninstalled libdrm and xf86-video-ati and the first built libdrm-git from aur. and after that i built xf86-video-ati-git. after a reboot everything was fine and games like openarena and apps like blender ran as smooth as never before...

wriggary · 2010-01-29 18:39:15

@labello:

does the brightness slider in openarena (or urbanterror if you have it) work again? As soon as I upgraded to xorg-server 1.7, the brightness slider does nothing, and i can't see anything on my favorite map (ut4_eagle!)

Labello · 2010-01-29 19:09:22

wriggary wrote:

@labello:
does the brightness slider in openarena (or urbanterror if you have it) work again? As soon as I upgraded to xorg-server 1.7, the brightness slider does nothing, and i can't see anything on my favorite map (ut4_eagle!)

no it does not work.

you should try to change the gamma-value within the config-file in ~/.openarena/baseoa/q3config.cfg

has anyone reported a bug?

EDIT: the two *-git packages in the AUR seem a bit outdated to me since the carry the suffix -git. is there any chance that the packages receive any update in the near future?

Last edited by Labello (2010-01-29 19:13:52)

tomk · 2010-01-29 22:28:24

Labello wrote:

the two *-git packages in the AUR seem a bit outdated to me since the carry the suffix -git.

The -git suffix is part of the package name, so that pacman knows they are not the same as libdrm and xf86-video-ati.

Labello wrote:

is there any chance that the packages receive any update in the near future?

makepkg automatically checks out the latest code from git when you build them, so they're never out of date.

devyn · 2010-01-29 22:50:13

Labello wrote:

the two *-git packages in the AUR seem a bit outdated to me since the carry the suffix -git. is there any chance that the packages receive any update in the near future?

Well, the PKGBUILD version only gets updated if there's anything wrong with the PKGBUILD itself. The version is automatically detected from the Git repository once everything is finished.

They're also not outdated at all, they automatically pull the latest version from the Git repository. there's also for example *-bzr, *-svn, *-darcs, *-devel, etc.

wriggary · 2010-01-29 22:52:14

mesa-git is having problems building, does anyone know if this is a makepkg issue or is the problem upstream?

devyn · 2010-01-29 22:54:11

wriggary wrote:

mesa-git is having problems building, does anyone know if this is a makepkg issue or is the problem upstream?

I'm pretty sure I had issues with it too. It seems to be an issue with the PKGBUILD. But I don't think you need the git version of mesa, normal mesa will do just fine.

The important ones are libdrm-git and xf86-video-ati-git.

wriggary · 2010-01-29 23:07:08

[facepalm]

I must have been thinking about an older revision of the radeon-archwiki... or another post. Just took another look at it, and yes, it says you can recompile them from the abs as long as those two packages (libdrm-git and xf86-video-ati-git) are compiled from the AUR. I need a cigarette and more coffee...

[offtopic]

Can we get a :facepalm: smiley? or maybe ...

I really need less firefox tabs open:

gary@leviathon:~$ ps aux | grep -i firefox
gary      1946  7.9 20.1 833664 206496 ?       Sl   14:22   7:46 firefox

Last edited by wriggary (2010-01-29 23:10:51)

devyn · 2010-01-30 07:26:20

wriggary wrote:

[facepalm]
I must have been thinking about an older revision of the radeon-archwiki... or another post. Just took another look at it, and yes, it says you can recompile them from the abs as long as those two packages (libdrm-git and xf86-video-ati-git) are compiled from the AUR. I need a cigarette and more coffee...
[offtopic]
Can we get a :facepalm: smiley? or maybe ...http://www.overlordforums.com/Smileys/d … cepalm.gif
I really need less firefox tabs open:
gary@leviathon:~$ ps aux | grep -i firefox
gary      1946  7.9 20.1 833664 206496 ?       Sl   14:22   7:46 firefox

Let me know if it all works out.

Arch Linux

#1 2010-01-15 00:15:36

[radeon] Falling back on software rendering after update

#2 2010-01-15 00:18:14

Re: [radeon] Falling back on software rendering after update

#3 2010-01-15 03:57:17

Re: [radeon] Falling back on software rendering after update

#4 2010-01-15 13:00:33

Re: [radeon] Falling back on software rendering after update

#5 2010-01-15 17:15:34

Re: [radeon] Falling back on software rendering after update

#6 2010-01-15 23:59:34

Re: [radeon] Falling back on software rendering after update

#7 2010-01-16 00:41:04

Re: [radeon] Falling back on software rendering after update

#8 2010-01-16 01:10:28

Re: [radeon] Falling back on software rendering after update

#9 2010-01-16 23:36:44

Re: [radeon] Falling back on software rendering after update

#10 2010-01-20 04:38:13

Re: [radeon] Falling back on software rendering after update

#11 2010-01-22 13:24:37

Re: [radeon] Falling back on software rendering after update

#12 2010-01-23 09:44:02

Re: [radeon] Falling back on software rendering after update

#13 2010-01-23 10:02:44

Re: [radeon] Falling back on software rendering after update

#14 2010-01-23 10:05:55

Re: [radeon] Falling back on software rendering after update

#15 2010-01-23 12:21:40

Re: [radeon] Falling back on software rendering after update

#16 2010-01-24 23:15:00

Re: [radeon] Falling back on software rendering after update

#17 2010-01-29 17:22:34

Re: [radeon] Falling back on software rendering after update

#18 2010-01-29 18:39:15

Re: [radeon] Falling back on software rendering after update

#19 2010-01-29 19:09:22

Re: [radeon] Falling back on software rendering after update

#20 2010-01-29 22:28:24

Re: [radeon] Falling back on software rendering after update

#21 2010-01-29 22:50:13

Re: [radeon] Falling back on software rendering after update

#22 2010-01-29 22:52:14

Re: [radeon] Falling back on software rendering after update

#23 2010-01-29 22:54:11

Re: [radeon] Falling back on software rendering after update

#24 2010-01-29 23:07:08

Re: [radeon] Falling back on software rendering after update

#25 2010-01-30 07:26:20

Re: [radeon] Falling back on software rendering after update

Board footer