AMD 8.36.5 Driver -- The Still no fglrx AIGLX Support Edition

[Michael]

A new driver is out! 8.36.5 features an updated Catalyst Control Center for Linux, Linux 2.6.20 support, and some bug fixes for AGP cards using PCI-E chips. No major changes outside of that.

Download Link: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-8.36.5-x86.x86_64.run
Release Notes: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.36.5.html

Last month the AMD Catalyst Control Center Linux Edition had entered the world with mixed opinions by the ATI/AMD Linux user community. In our 8.35.5 Linux driver review we had looked at the Linux version of the Catalyst Control Center quite extensively. This new control center replaced the old fireglcontrolpanel and in our opinion was a huge move for AMD. However, the negativity against the Catalyst Control Center has been by those seeking the much overdue AIGLX support. While today's 8.36.5 release doesn't contain AIGLX support, it does contain a few changes worth mentioning.

However, from the article:

While not marked in the official release notes, there have been some "under the hood" changes with the fglrx 8.36 driver. In this driver are two new files: esut.a and glesx.so. These are new X.Org modules for the fglrx driver and specifically involve TexturedVideo and OpenGL ES. The changes that stem from this should be very interesting and when the time comes for its implementation we will be sure to share all of the details.

http://www.phoronix.com/vr.php?view=9521

(This is also the last review until the "new Phoronix" on Friday)

[mlau]

OpenGL ES


oooh... does that mean that theres Linux support for the Imageons in the works? (for MIPS/SH/ARM/PPC even?)

[Michael]

Digg Link: http://www.digg.com/linux_unix/ATI_8_36_5_Display_Driver_Released

[yoshi314]

i'm going back to 8.35, and waiting for 8.37. this is the worst release ever for me.

even simple mpeg videos (~400x300 resolution) are unfiltered and skip awfully now (every second). it makes an impresison that 2d acceleration dissapeared somewhere, although xvinfo says that everything's ok.

yes, the release notes mention it, but i didn't expect that the issues were so serious. i thought that there was minor tearing on video, but it's really bad.

[sundown]

Yeah, visible decrease.
Anyway, Ubuntu 7.04 is out tomorrow so I guess they rushed to release this with the new kernel support.

[yoshi314]

weird. does ati really care about ubuntu that much?

[d2kx]

It hasn't anything to do with Ubuntu, be sure!

Interesting as I had the VERY annoying problem which is hopefully fixed now (console switching crash). Will test it later this week...

[Michael]

ATI did not time this release for Ubuntu Feisty Fawn...

[giorgosts]

I can confirm the video playback problem. Although glxinfo, xvinfo and xine-check report full acceleration, cpu shoot up to 30-40% from 0-2% in the 8.35.5 release. Best option for me is to disable video overlay. As I had done in all previous releases due to the cropping bug on tv-out. Intrestingly enough, the cropping bug on tv-out is gone, but so did the acceleration. In addition, video on my primary CRT monitor segfaults X.

[mlau]

even simple mpeg videos (~400x300 resolution) are unfiltered and skip awfully now (every second). it makes an impresison that 2d acceleration dissapeared somewhere, although xvinfo says that everything's ok.


What card do you have? I have absolutely no problems playing
1080p videos on the mobility9600

[hobbes]

I already test it:


Sapphire X1650 pro AGP 512MB

openSUSE 10.2 x86-64

Kernel 2.6.20.6


Switch to text mode and back to X is working now!


I noticed better performance moving and resizing windows.


I use openGL to playback videos on mplayer and xine and so far i have not noticed any problems, working as 8.35.5 did.


PS: When switching to text mode sound playback stops while been there and back to work when return to X.

[gfxdrone]

At first it appeared that ATI had finally gotten it right. Drivers install fine on 2.6.20.x kernels, no problems. First install, no problems. amdccle install of course still not working, but that's irrelevant. But then on further testing, we discovered that on debian sid based systems, on driver deb uninstall, something is going wrong, this has been confirmed by two users so far.

When they start x after the reinstall (not the initial 8.36.5 install, which is fine for them) of 8.36.5, they see screen and font corruptions. symptoms include icon jaggedness, weird looking fonts on desktop.

This is just preliminary, I don't know what the real problem is that is causing something to be changed on deb uninstall, but it's something real.

Installing an older driver does not appear to resolve this issue, which suggests that either a configuration file or some other xorg component was modified. Also mouse pointer was changed to 'an ugly' one, so something really changed on uninstall. We've never seen this particular issue before by the way.

Pulling this driver until I can get this issue resolved, although users did report higher initial framerates etc, but it's not worth the damage it's doing on reinstall..

Installs running 2.6.20.6 and 2.6.20.7 kernels.

[gfxdrone]

Update: we've found that restoring the xorg ati driver makes the screen display correctly again. This sounds like the ati pre install uninstaller may be removing some file it's not supposed to be removing, and which fglrx needs but ati does not, since older fglrx drivers do not correct the display issues. I have the feeling that this may be enough information to figure it out, we're going to try to get a installed packages list diff between pre install and post install and pre reinstall and reinstall.

Unless someone can think of anything else, that's all I can think to test now.

[glussier]

I installed the drivers on 3 different computers and 2 linux distros, and everything is working fine, 3d opengl, playing video and tv card. all works fine.

AMD 3200+ Abit nf7, 1gB mem, 9600Pro agp, Fedora 6

P4EE 3.73ghz Asus P5WD2 Premium, X700Pro pcie, Fedora Core 6

P4R 550 (3.4ghz) Asus P5WD2 Premium, x850Pro pcie, Slackware 10.2

[yoshi314]

What card do you have? I have absolutely no problems playing
1080p videos on the mobility9600X1300Pro.

besides, disabling TexturedVideo, and keeping VideoOverlay on causes awful glitches with video playback (i think it appeared a couple of releases ago). i'll try tinkering with opengl overlay, then.

[aljaz]

I also have X1300Pro and Ubuntu 7.04 AMD64 bit with a custom 2.6.20.7 kernel. After installing the new driver no video playback program would start - the application window (tried totem and xine) would just pop up for a split moment and then close again without any log entries. I reverted back to 8.35 and video playback is there again.

But the 8.35 driver is giving me headache because it randomly freezes the system but where I can repeat the freeze everytime is to use switch user option in Ubuntu. It does not happen with the first switch to other user but when switching back. The log says fglrx is having problems and needs restarting the system (the log I can look after I restart the frozen system).

[the-me]

I've to say, for me is this new 8.36.5 release a disaster.

On the system start, my Xv is working well (xvinfo/xine-check).
But if I try to play any video (mpg/avi/mov) with xine (using Xv), Xv corrupts.
So xine crashed and after this corrupt, xvinfo and xine-check says, that Xv isn't supported. On rebooting I saw a little stacktrace of my X server and in the .xsession-errors, there were a few errors about Xvideo, like bad argument.

I'm using Debian Sid, 2.6.18 deb Kernel and a PCI-E Sapphire Radeon 1650 Pro card.

[yoshi314]

i *really* hope that they'll release a hotfix quickly, e.g. by the end of the month.

[Michael]

i *really* hope that they'll release a hotfix quickly, e.g. by the end of the month.


Don't count on it but 8.37 may be here early in May.

[lenrek]

I manage to download and install the driver. So far, no noticeable problem.

Reading many replies so far, I guess I should consider myself lucky.

[gfxdrone]

It appears possible that some config file in ~/ was altered. At least this is a possibility because a user restored / but not /home, and the issue persists on fresh install of 8.35.5 or 8.36.5. But it's very hard to know what is wrong.

Distortions vanish when users revert to native xorg ati drivers, when that's possible.

One thing I do know, anyone who deliberately buys an ATI powered gfx card is making a bad mistake if they want to run Linux based systems long term. Or short term often.

[yoshi314]

that depends on whether there are open drivers for the card or not.

[gfxdrone]

Looks like we found the solution: we were using the syntax recommended here (http://www.phoronix.net/forums/showthread.php?t=1772), ati phoronix forums:

Section "Extensions"
Option "Composite" "Disable"
Option "RENDER" "Disable"
Option "AIGLX" "Disable"
EndSection

and that caused the issue it appears. After rolling it back to this:
Section "Extensions"
Option "Composite" "0"
# Option "RENDER" "1"
EndSection

the problem instantly vanished. Since the first method was based on advice from here, I'd suggest you take another look at this syntax before recommending it again.

I just noticed a poster also pointed out the error in your syntax, and other errors in that thread.

[yatt]

I have upgraded to the 3.36.5 driver. No weird video bugs, but amdcccle won't launch. It cannot find the file, even when I drag it into a terminal to launch it.

[aljaz]

Section "Extensions"
Option "Composite" "0"
# Option "RENDER" "1"
EndSection

the problem instantly vanished. Since the first method was based on advice from here, I'd suggest you take another look at this syntax before recommending it again.


It works for you? I still got the same result with video playback. I even started xine in terminal just to get BadMatch and something about Overlay (Xv).

[yatt]

Anyone else notice that when running XGL, none of the apps are aware that the desktop is in dual-head mode?

I don't know if this is the fault of Feisty's XGL or the new driver, but now my panel spans both monitors and apps start centered at the border between monitors (compared to centered in the monitor my mouse is currently in).

[time2IPL]

A new driver is out! 8.36.5 features an updated Catalyst Control Center for Linux, Linux 2.6.20 support, and some bug fixes for AGP cards using PCI-E chips. No major changes outside of that.


Hi, Michael -

From everything I've seen, you seem to be the one to ask. I posted a new question appx 2 days ago (either yesterday or the day before, I don't remember if it was before midnight or after) regarding the card I'm using; lspci id's it as a "ATI Technologies Inc RV530 [Radeon X1600]"; my Xorg log concurs:
"(--) PCI:*(2:0:0) ATI Technologies Inc RV530 [Radeon X1600] rev 0, Mem @ 0xe0000000/28, 0xf3000000/16, I/O @ 0xa000/8
(--) PCI: (2:0:1) ATI Technologies Inc RV530 [Radeon X1600] (Secondary) rev 0, Mem @ 0xf3010000/16"

and

"(II) fglrx(0): Primary V_BIOS segment is: 0xc000
(--) fglrx(0): Chipset: "Radeon X1600 Series (RV530 PRO 71C2)" (Chipset = 0x71c2)
(--) fglrx(0): (PciSubVendor = 0x1002, PciSubDevice = 0x2342)
(--) fglrx(0): board vendor info: original ATI graphics adapter
(--) fglrx(0): Linear framebuffer (phys) at 0xe0000000
(--) fglrx(0): MMIO registers at 0xf3000000
(==) fglrx(0): ROM-BIOS at 0x000c0000"

Your post mentioned something about "AGP cards using PCI-e chips". This is a PCI-e card; I didn't realize there was more than one kind of PCI-e card - or perhaps I'm misreading your post...

In any event, if you wouldn't mind clarifying for me what the heck the card I have is (if you have a spare minute and could give the message I posted 1-2 days ago, that would be wonderful) - and point me in the right general direction as to what to try next - I would really, really appreciate it.

Thanks,

Larry (time2IPL)

[Michael]

Hi, Michael -

From everything I've seen, you seem to be the one to ask. I posted a new question appx 2 days ago (either yesterday or the day before, I don't remember if it was before midnight or after) regarding the card I'm using; lspci id's it as a "ATI Technologies Inc RV530 [Radeon X1600]"; my Xorg log concurs:
"(--) PCI:*(2:0:0) ATI Technologies Inc RV530 [Radeon X1600] rev 0, Mem @ 0xe0000000/28, 0xf3000000/16, I/O @ 0xa000/8
(--) PCI: (2:0:1) ATI Technologies Inc RV530 [Radeon X1600] (Secondary) rev 0, Mem @ 0xf3010000/16"

and

"(II) fglrx(0): Primary V_BIOS segment is: 0xc000
(--) fglrx(0): Chipset: "Radeon X1600 Series (RV530 PRO 71C2)" (Chipset = 0x71c2)
(--) fglrx(0): (PciSubVendor = 0x1002, PciSubDevice = 0x2342)
(--) fglrx(0): board vendor info: original ATI graphics adapter
(--) fglrx(0): Linear framebuffer (phys) at 0xe0000000
(--) fglrx(0): MMIO registers at 0xf3000000
(==) fglrx(0): ROM-BIOS at 0x000c0000"

Your post mentioned something about "AGP cards using PCI-e chips". This is a PCI-e card; I didn't realize there was more than one kind of PCI-e card - or perhaps I'm misreading your post...

In any event, if you wouldn't mind clarifying for me what the heck the card I have is (if you have a spare minute and could give the message I posted 1-2 days ago, that would be wonderful) - and point me in the right general direction as to what to try next - I would really, really appreciate it.

Thanks,

Larry (time2IPL)

You are running a PCI Express system and are in the clear of the mentioned bug fix.

Using the Rialto bridge, ATI can offer some native PCI-E GPUs with an external AGP interface. So that they could sell like a Radeon X1600 as an AGP card without using a different GPU than the PCI-E X1600. Essentially just a PCI-E -> AGP converter.

[yoshi314]

do they work with xorg-server-1.3.0 ? i don't want to compile it in vain :]

[DarkFoss]

Well after using the 8.36.5's I'm going back to the 8.35.5 drivers and await the 8.37's.
Those worked fine for me. The latest gives me issues with vid playback as well as increased cpu usage with no noticable improvements. ahh well.

[Michael]

do they work with xorg-server-1.3.0 ? i don't want to compile it in vain :]

No xorg-server 1.3 support :mad:

[yoshi314]

ati linux team - world's worst job :P

seriously, i am now strongly considering sticking with my old crappy x300se on open drivers, until the open r500 driver pops up.

[shinytoaster]

The mouse pointer alignment issue with dual monitors running different resolutions finally got fixed, after driving insane for the past six months. Now if they could fix the composite issue I'll be happy with the fglrx drivers for the first time ever.

[sundown]

The mouse pointer alignment issue with dual monitors running different resolutions finally got fixed, after driving insane for the past six months. Now if they could fix the composite issue I'll be happy with the fglrx drivers for the first time ever.

Are we talking about the thing where the pointer rather becomes a square with transparent stripes? Coz I still've got that.

[shinytoaster]

Are we talking about the thing where the pointer rather becomes a square with transparent stripes? Coz I still've got that.

No this is where the mouse pointer visually isn't actually where the pointer is, so you do not know where you're clicking. Only happened on dual monitor setups of different res.

[time2IPL]

Using the Rialto bridge, ATI can offer some native PCI-E GPUs with an external AGP interface. So that they could sell like a Radeon X1600 as an AGP card without using a different GPU than the PCI-E X1600. Essentially just a PCI-E -> AGP converter.

Ahh. Thanks; I didn't know that technology was available commercially yet. Keeping up with what you can do is difficult enough; once you add "what's on the market" to that, s/difficult/damn-near-impossible/.

The only thing I don't get is, if the AGP bus is - and was - the limiting factor, then what's the advantage of this setup to the end-user? Or is it more a way for vendors to get 2x the product out of a given GPU / chipset / etc. - and possibly a way to use chips that can't pass QI for PCI-e but might work just fine on an AGP card that's lower-end than the PCI-e card they were originally made for?

Or was PCI-e really just never really the be-all and end-all for the bulk of us...

Thanks,
Larry

[DarkFoss]

I'd imagine using the adapter is a cost saving measure that way they don't have to produce 2 versions of the same card. I haven't seen any benches involving the adapter so I don't know it there is any performance penalty for using one. I've been thinking about trying it when I buy my next vid card so when I do move to PCI-E I can just keep using the same card.

PCI-e is definitely a faster way to transport the data but last time I checked no games were coming anywhere close to saturating the 8x agp bus. IMO, I don't think there's a huge advantage unless you want to run sli/crossfire or do a large amount of gaming with todays most demanding games.

[Svartalf]

The only thing I don't get is, if the AGP bus is - and was - the limiting factor, then what's the advantage of this setup to the end-user? Or is it more a way for vendors to get 2x the product out of a given GPU / chipset / etc. - and possibly a way to use chips that can't pass QI for PCI-e but might work just fine on an AGP card that's lower-end than the PCI-e card they were originally made for?


There's not really an advantage to the end-user. It's more of an advantage to the marketing and sales people. It's more of a way to eke out 2X for the chip- as you surmised.


Or was PCI-e really just never really the be-all and end-all for the bulk of us...


It's been slightly overhyped. It's an opportunity to have all the disparate buses (AGP, PCI-X, PCI, etc...) all unified into a new cleaner spec that handles basic (PCI-E 1x- handles most PCI device situations) and high-end (PCI-E 16x- handles GPUs, ultra-fast channel adapter devices...) with the same basic bus, just more lanes to speed up things with. It's something to allow the chip and device (which includes mobos...) vendors a way to clean their house and have a consistent way to do things instead of conflicting and confusing ways. It allows me to do things like build supercomputer clusters with Infiniband or iWARP devices without needing server motherboards (PCI-X 66/100/133 would be your only OTHER option for the devices...) and so forth.

[Alistair]

I already test it:


Sapphire X1650 pro AGP 512MB

openSUSE 10.2 x86-64

Kernel 2.6.20.6

I noticed better performance moving and resizing windows.


I use openGL to playback videos on mplayer and xine and so far i have not noticed any problems, working as 8.35.5 did.
.

Hobbes!
my friend, my long lost hero :D

I recently decided that an upgrade was in order -- I've one of these critters -- although mines an official ATI card.
ati X1650 Pro - AGP ( chipid is 71C1 )

I've been beating my brains out getting this beast to work on an amd64 system. I've gotten it to work without DRI and and truth told, Im impressed on teh improvement over the 9600 just with the way it now renders fonts on my desktop -- lcd screen -- however - I enable dri and it stops dead at dri installation complete....

could you (most kindly) let me know what kernel options (i.e agp/agpgart etc) and what config you have in the device section for fglrx on your system... PLEASE -- before I convice myself I've misspent $200!

Most humbly in your debt!

[niniendowarrior]

I've really lost track of these AMD drivers. Michael, does it fix, 'on paper' fix my problem with AGP? I'm not bothering to download otherwise.

[d2kx]

What AGP problems?

I hope 8.37 will be released today... or tomorrow. But I think we'll have to wait till next week :(

[niniendowarrior]

It's really some time ago. Months... I reckon. I upgraded my driver and then fglrx would complain something about my AGP. Whatever. I couldn't get 3D acceleration ever again. Ever. Dropping to older versions didn't help at all. No support, no nothing. So, there is my good for nothing graphics card sitting there and me hoping for drivers that do work.

[time2IPL]

... I couldn't get 3D acceleration ever again. Ever. ...

In the process of trying to get the f%$&*! drivers working I trashed my X11 setup; I'm using FC6 64-bit. I had read several places that I should build a kernel without kernel DRM/DRI support && also make sure I had the nVidia drivers installed for my board (I'm using a Gigabyte GA-M55Plus-S3G (v1.0)) motherboard which has the Ge-Force 430 chipset on it) - you can probably pretty much guessed what happened; the nVidia driver install has pretty much trashed my X installation.

Can anyone give me some tips on how to remove && reinstall X? I'm assuming I'm going to need it and mesa; I've downloaded all the current RPMs for both. The server's made up of at least 50 different RPMS though; I don't particularly want to trash this installation and start agin (either on purpose or by accident) and my best guess is to forcibly remove & (re)install all of the RPMs yum & RPM show are installed on it now; I'm concerned that I'll miss something though.

Thanks very much,
Larry Morley

BTW Michael, if you're back in town, and have the time to go into the differences between the drivers from 8.32.5 and upwards, I'd really appreciate it; I've confirmed that there are, in fact, differences between where the installer puts libraries etc. on my system between driver versions. Thanks.

[d2kx]

I hope fglrx 8.37 comes today... and they better have AT LEAST Xorg 1.3 Support.

[Michael]

I hope fglrx 8.37 comes today... and they better have AT LEAST Xorg 1.3 Support.

Phoronix.com will be immediately adopting Fedora 7 once released (next week) to replace existing Fedora Core 6 and Fedora 7 Test 4 installations. Fedora 7 uses X.Org 1.3 :)

[d2kx]

Thanks for the information without breaking your AMD-Betatester-NDA :D Now try to do the same with the release date :D

[time2IPL]

Hi, Michael -

Just wondering if you were back in town and had a spare few to answer the questions I had had regarding changes in the drivers from 8.32.5 to all versions > 8.32.5; I'm still having the same problem(s), now with more machines.

I've taken this as far as I can go without the benefit of your assistance (as packager of the drivers) or some other rather deep technical insight. At this point, I really need to resolve this - somehow. I posted another summary regarding the latest system that won't work with any driver > 8.32.5; it's a completely different system, card, etc. than my others; about the only thing they have in common is FC6 (and its X server, etc.).

Thanks in advance for your help,
Larry Morley

[Michael]

Yes, I am now back from JavaOne and almost caught up in all the work.

In 8.32.5 was the 2.6.19 support in the mainstream code, switching from using system-config-display to aticonfig for the X configuration. In 8.33.6 atiogl_a_dri.so was removed since that was a blob related to R200 that was removed from the driver itself. /etc/ati/control was also introduced mainstream in that version.

In 8.34 was Fedora 7 support with a Linux 2.6.20 patch (temporary). In 8.35 fireglcontrolpanel was removed and then linked to the new Catalyst Control Center.

Then in 8.36 the Linux 2.6.20 patch was removed along with adding esut.a and glesx.so..

[time2IPL]

Yes, I am now back from JavaOne and almost caught up in all the work.

First, thanks for getting back to me; I know how much of a joy it is trying to get caught up (or kept up). Second, thanks for the history; hopefully, it'll help explain what happened.

I verified again that the version 8.33.6 is the one where X on the systems I'm trying to get working here go off into the weeds upon attempting to load libfglrxdrm.so. That's consistent with the fact that the server starts up (albeit without DRI/DRM support) if I make libfglrxdrm.so unavailable. The problem has occurred with every Radeon X1600 (R500 based) I've tried, and also with two 9800s (R350 based AGP cards). In all cases the OS was FC6, and version 8.32.5 of the driver works.

Tried mixing peices of different driver versions (eg., to see if adding back in atiogl would allow the driver to work, etc.); but, the X server detected the version mismatch and wouldn't load.

So, at this point, it would appear that the question is one of "what do several X1600 / R500 cards and two Radeon 9800's (R350) have in common with the 200's, so much so that removing a chunk of code to support one would affect the other?" As far as I can tell, the code for libfglrxdrm isn't published, so there's not much I can do there...

It almost has to be something simple. Either that, or I'm missing something that's dead obvious. Either way, I would love to know what's going on.

What I was seeing with respect to file locations seems to be related to how the driver is instaled (eg., as a module, or as a group of RPMs). I hecked that again too, and there are quite a few differences as fa rwhere

Does anything at all spring to mind? This iust too bizarre.

Thanks again,
Larry

[Michael]

Is there any errors in your Xorg.0.log or anything "weird" in your xorg.conf? I have done at least 50 new Fedora installs since 8.32 and haven't run into a issue like you describe.

[lenrek]

Is there any errors in your Xorg.0.log or anything "weird" in your xorg.conf? I have done at least 50 new Fedora installs since 8.32 and haven't run into a issue like you describe.

Maybe you can check his thread:

http://phoronix.net/forums/showthread.php?t=2828

[Michael]

Is there any errors in your Xorg.0.log or anything "weird" in your xorg.conf? I have done at least 50 new Fedora installs since 8.32 and haven't run into a issue like you describe.

Have you tried reverting to a very simple xorg.conf? A configuration as basic as you can have, just to see if it starts up properly?

[d2kx]

No fglrx 8.37 this week :(

[time2IPL]

Is there any errors in your Xorg.0.log
Nope; just two benign warnings from statements that aticonfig itself puts in the thing:

$ grep WW /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(WW) fglrx: No matching Device section for instance (BusID PCI:2:0:1) found
(WW) fglrx(0): Option "VendorName" is not used
(WW) fglrx(0): Option "ModelName" is not used
$ grep EE /var/log/Xorg.0.log
Current Operating System: Linux zeus.cslimits.net 2.6.20-1.2948.ljm #1 SMP PREEMPT Mon May 7 16:57:11 EDT 2007 i686
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(II) Loading extension MIT-SCREEN-SAVER



or anything "weird" in your xorg.conf?

No there too; I have tried a lot of different settings (and combinations of settings); none of them ever made a difference with respect to the lockup-on-X-startup problem though. Currently, xorg.conf reads:


Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "aticonfig-Screen[0]" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
FontPath "unix/:7100"
EndSection

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

Section "ServerFlags"
Option "AIGLX" "off"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "yes"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection

Section "Monitor"
Identifier "aticonfig-Monitor[0]"
Option "VendorName" "ATI Proprietary Driver"
Option "ModelName" "Generic Autodetecting Monitor"
Option "DPMS" "true"
DisplaySize 340 270
HorizSync 31.0 - 80.0
VertRefresh 56.0 - 75.0
EndSection

Section "Device"
Identifier "aticonfig-Device[0]"
Driver "fglrx"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]"
Device "aticonfig-Device[0]"
Monitor "aticonfig-Monitor[0]"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024" "1152x864" "1024x768" "800x600"
EndSubSection
EndSection

Section "DRI"
Group 0
Mode 0666
EndSection

Section "Extensions"
Option "Composite" "False"
Option "XVideo" "Enable"
EndSection


As far as I know that's about as vanilla as one can get it - again, though, if I'm missing something obvious...

I have done at least 50 new Fedora installs since 8.32 and haven't run into a issue like you describe.

All in (more or less) the following manner, right?


rpm -e `rpm -qa | grep "^ATI"`
rpm -e `rpm -qa | grep "kernel-module.*ATI"`


and then either:


sh ./ati-driver-installer-8.x.y-x86.x86_64.run --buildpkg Fedora/FC6


or


sh ./ati-driver-installer-8.x.y-x86.x86_64.run --extract
cd fglrx-install*
<apply any patches, etc. needed here...>
sh ./ati-installer.sh 8.x.y --buildpkg Fedora/FC6
cd ..


and finally


rpm -Uvh --force `ls *.rpm`


or


rpm -Uvh --force *.rpm


etc.

I'm certain that I'm not having an rpmbuild problem; I can always managed to get the RPMs to build; they have everything they're supposed to have, at least according to rpm -qipl - but, for whatever reason, my track record is 180 degrees out of phase with yours; I have not yet been able to get one single card working with anything newer than 8.32.5. On one machine, I even tried using the livna drivers; the results were exactly the same.

What's even more peculiar is I can't seem to screw the "vintage" drivers up: I can remove the 8.32.5 driver using rpm -e, or rm it's files, or whatever - at which point X won't start - but, upon reinstalling it (w/ rpm -Uvh --force), X comes back to life every single time.

Is there *anything* that looks out of order, unusual, shouldn't be there, etc. in the above? There's gotta be something I'm either missing, overlooking, etc. This is just too wierd.

Thanks
Larry

[krypton]

do any1 know if AIGLX will ever come? I am soon switching to NVidia. this is fu'''ng annoying. I want to play win games (like counter-strike) with OpenGL AND have Beryl, without logging in and out all the time. This, AMD, is crappy work.

[Michael]

do any1 know if AIGLX will ever come? I am soon switching to NVidia. this is fu'''ng annoying. I want to play win games (like counter-strike) with OpenGL AND have Beryl, without logging in and out all the time. This, AMD, is crappy work.

It is coming.

[time2IPL]

Michael -

Have you tried reverting to a very simple xorg.conf? A configuration as basic as you can have, just to see if it starts up properly?

I think our posts & replies are starting to overlap / cross; sorry about that. In the message I posted just prior to this one, in response to your question (above), I indicated that yes, I have tried a simple xorg.conf. I've tried others, too; none of them make a difference for drivers version 8.32.5 and up. In that same post, I also outlined the installation procedure I've been using; perhaps there's something there I'm missing. The other post which someone referenced earlier (http://phoronix.net/forums/showthread.php?t=2828)) I made after encountering the exact same problems on a completely different machine (different processor, different motherboard, card was AGP as opposed to PCI-e & had a different series (it was a R350 as opposed to R500)).

At any rate, thanks for the help, and sorry for the confusion; just so it's clear what the heck I'm talking about, I've tried both simple and esoteric xorg.conf's; I've tried stock kernels and my usual custom tailored one. About the only thing that seems to make a difference is whether or not DRI/DRM is actually running; after going over the ptrace, etc. output I gathered after I ran xinit under it, the drivers are all dying after libfglrxdrm.so loads; once that library is loaded by Xorg, the server goes off into some sort of loop where it's busy-waiting (in ring 0 code), the system deadlocks, etc.; if I can keep it from loading, X comes up - but I don't have DRI, and therefore, don't have accellerated graphics functionality - so it'd be extremely presumptious for me to say "this is all due to libfglrxdrm.so".

That said, is there anything "funny" about Fedora Core 6's X server? Or DRM/DRI implementation?

As I noted in the other post (http://phoronix.net/forums/showthread.php?t=2828) I did find an older howto and tried following it; it stated the kernel had to be rebuilt without DRM/DRI support; all that resulted in was no DRI, at all, though, and no improvement.

Is my installation procedure the same as the one you've been using? I can post the kernel config I'm using currently; however, since nothing I've changed there has had any effect on X, I've held off on doing that to avoid further clouding the issue.

This is really, really strange; at this point, I would say it almost has to come down to a simple, seemingly trivial thing that I'm either missing, or have installed and shouldn't; or that I'm doing, or not doing; etc.

Thanks again,

Larry

[Alistair]

Michael:
You seem to be the wiz about these fora, can you tell me if there is any particular issue getting the AGP version of pcie cards running on these drivers?
Is there some hidden, undocumented elsewhere setting in xorg.conf or in module parameters for fglrx that I can set to make my hot new card work?
My trusty 9600 is back in and works a charm on the xorg.conf I set up for the X1650 Pro, all is working on either DVI out or AGP out and no problems with vt switching on 8.35.5. 8.36.5 works as well. The 1650 agp stops *dead* at dri installation complete.
The errors in Xorg.0.log while loading the drivers for the X1650Pro are :
(grep -e WW -e EE Xorg.0.log)

(WW) The directory "/usr/share/fonts/TTF/" does not exist.
(WW) The directory "/usr/share/fonts/OTF" does not exist.
(WW) The directory "/usr/share/fonts/CID/" does not exist.
(WW) Ignoring unrecognized extension "AIGLX"
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(EE) end of block range 0x7ffffff < begin 0xf0000000
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
(EE) end of block range 0x7ffffff < begin 0xf0000000
(WW) LoadModule: given non-canonical module name "glesx.so"
(WW) fglrx(0): Option "IgnoreEDID" is not used
(WW) fglrx(0): Option "NoTV" is not used
(WW) fglrx(0): Option "DynamicClocks" is not used
(WW) fglrx(0): Option "VendorName" is not used
(WW) fglrx(0): Option "ModelName" is not used


I'm not sure what the 'end of block range' errors mean and I can't see the glesx.so warning being a blocker. Typically it looks like ATI is scrapping some options from the driver settings without telling us...

Any Suggestions hints, tips, tricks or moderate abuses of sanity?

(Gentoo, 2.6.20 r7, Nforce2, Amd64, LCD @ 1440x900 on agp or dvi, 25 years computer systems experience from mainframe to pc to unix to networks)

[Michael]

Can you post your xorg.conf? I don't know the last time I touched an AGP card, but in a recent driver there was a fix for AGP cards using a PCI-E chipset with a Rialto bridge.

I can look around and ask some people at AMD if need be. I've ran into a few other people recently that have the same problem (or close to the same problem) as yours.

[Alistair]

Can you post your xorg.conf? I don't know the last time I touched an AGP card, but in a recent driver there was a fix for AGP cards using a PCI-E chipset with a Rialto bridge.

I can look around and ask some people at AMD if need be. I've ran into a few other people recently that have the same problem (or close to the same problem) as yours.

I'm fairly sure this is pretty plain...



#xorg.conf
# File generated by xorgconfig.
#
# Copyright 2004 The X.Org Foundation
Section "Module"

Load "glx"
#Load "GLcore
Load "dri"
# Load "dbe" # Double buffer extension
Load "extmod"
SubSection "extmod"
Option "omit xfree86-dga" # don't initialise the DGA extension
Option "omit XVideo"
EndSubSection
Load "fbdevhw"
Load "type1"
Load "freetype"
Load "record"

EndSection


Section "Files"

FontPath "/usr/share/fonts/misc/"
FontPath "/usr/share/fonts/Type1/"
FontPath "/usr/share/fonts/100dpi/"
FontPath "/usr/share/fonts/75dpi/"
EndSection

Section "InputDevice"
Identifier "Keyboard1"
Driver "kbd"
Option "AutoRepeat" "500 30"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"

Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "Auto" # Auto detect
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
Option "Emulate3Buttons"

EndSection

Section "Monitor"
Identifier "aticonfig-Monitor[0]"
Option "VendorName" "ATI Proprietary Driver"
Option "ModelName" "Generic Autodetecting Monitor"
Option "DPMS" "true"
EndSection

Section "Device"
Identifier "aticonfig-Device[0]"
Option "IgnoreEDID" "off"
Option "NoTV" "yes"

Driver "fglrx"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]"
Device "aticonfig-Device[0]"
Monitor "aticonfig-Monitor[0]"
DefaultDepth 24
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Simple Layout"
Screen 0 "aticonfig-Screen[0]" 0 0
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
# Option "AIGLX" "false"
EndSection

Section "Extensions"
Option "Composite" "disable"
EndSection

Section "DRI"
Mode 0666
EndSection



I've also run this with the xorg.conf down to pretty barebones options -- -dri/glx/freetype and just about nothing else...

[time2IPL]

Hi, Michael -

Have you tried reverting to a very simple xorg.conf? A configuration as basic as you can have, just to see if it starts up properly?

Set xorg.conf to the plain version I posted yesterday on three different machines, still no luck / no difference. I did, however, remember / notice that the numbers fglrx reported in /var/log/messages / dmesg didn't seem to correspond to anything:


[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 250081280
[fglrx] max single LFB = 250081280
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0


I don't know what these numbers mean; but, in looking over posts from others, I don't recall seeing others posted with "0" for any of these totals, except in instances where someone is/was having the same problem I am; there are quite a few of us...

Was also wondering about the BIOS setting for aperature size && PCI-e cards; does how that's used vary from motherboard to motherboard or ??? If it does (or should) matter, what does the driver expect it to be set to? I have a choice of "disabled", 16Mb, 32Mb, 64Mb & 128Mb; none of the values match the amt of memory on my card (512Mb). Again, the card is PCI-e but the motherboard has on-board AGP graphics - which should be disabled, right?

Setting makes no difference as far as I can tell w 8.32.5 driver, and if there is a magic one for later drivers, I haven't found it yet.

Do the numbers above seem correct for a 512Mb PCI-e X1600 (RV530) card in a system w/2Gb RAM, with aperature currently set to 128Mb?

Thanks,
- Larry

[Michael]

Hi, Michael -



Set xorg.conf to the plain version I posted yesterday on three different machines, still no luck / no difference. I did, however, remember / notice that the numbers fglrx reported in /var/log/messages / dmesg didn't seem to correspond to anything:


[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 250081280
[fglrx] max single LFB = 250081280
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0
I don't know what these numbers mean; but, in looking over posts from others, I don't recall seeing others posted with "0" for any of these totals, except in instances where someone is/was having the same problem I am; there are quite a few of us...

Was also wondering about the BIOS setting for aperature size && PCI-e cards; does how that's used vary from motherboard to motherboard or ??? If it does (or should) matter, what does the driver expect it to be set to? I have a choice of "disabled", 16Mb, 32Mb, 64Mb & 128Mb; none of the values match the amt of memory on my card (512Mb). Again, the card is PCI-e but the motherboard has on-board AGP graphics - which should be disabled, right?

Setting makes no difference as far as I can tell w 8.32.5 driver, and if there is a magic one for later drivers, I haven't found it yet.

Do the numbers above seem correct for a 512Mb PCI-e X1600 (RV530) card in a system w/2Gb RAM, with aperature currently set to 128Mb?

Thanks,
- Larry

Larry,

The aperture size shouldn't cause the DRI issues you are experiencing.

I left a message this morning with AMD, and am waiting on hearing back from them since it seems a number of people with PCI-E GPU -> AGP interface cards are running into problems.

Though 8.32 is working for you, have you tried upgrading your kernel or updating any other packages?

I would also suggest upgrading to 8.37 once available to see if the issue can be reproduced there.

[Alistair]

Hi, Michael -



Set xorg.conf to the plain version I posted yesterday on three different machines, still no luck / no difference. I did, however, remember / notice that the numbers fglrx reported in /var/log/messages / dmesg didn't seem to correspond to anything:


[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 250081280
[fglrx] max single LFB = 250081280
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0


I don't know what these numbers mean; but, in looking over posts from others, I don't recall seeing others posted with "0" for any of these totals, except in instances where someone is/was having the same problem I am; there are quite a few of us...



Larry
Just checked on my running (working) agp card -
ATI Technologies Inc RV350 AS [Radeon 9550]
(the box said 9600 of course but sapphire clearly lies *grin*)

I have the following in dmesg (and World of Warcraft currently running in wine, on opengl)

agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[fglrx] AGP enabled, AgpCommand = 0x1f004312 (selected caps)
[fglrx] total GART = 134217728
[fglrx] free GART = 118222848
[fglrx] max single GART = 118222848
[fglrx] total LFB = 134217728
[fglrx] free LFB = 116002816
[fglrx] max single LFB = 116002816
[fglrx] total Inv = 134217728
[fglrx] free Inv = 134217728
[fglrx] max single Inv = 134217728
[fglrx] total TIM = 0


so lets see --

I'm running an nforce2 chipset and an amd64 (64bit) installation, the bios on this motherboard ***does not have*** a GART apeture modification setting.
This is a 939 pin socket AMD 64 (single core).

Assume a default 128Mb apeture, and that GART total makes sense (bits not bytes),

and we have this as well:


(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.35.5
ABI class: X.Org Server Extension, version 0.3
(--) fglrx(0): VideoRAM: 131072 kByte, Type: DDR SGRAM / SDRAM
(II) fglrx(0): AGP card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)


Which isn't quite right either, since my card clearly has 256Mb on board, but it appears to be split 50/50 for the two heads.

(again the numeric differences are likely due to bits/bytes/kb/Kb)

one interesting table I've found along my travels with ATI products is in

/proc/dri/0/mem



total counts | outstanding
type alloc freed fail bytes freed | allocs bytes
system 0 0 0 1577525248 18446604435732824064 | 0 -4294967296
locked 202 189 0 111013888 96141312 | 13 14872576
sareas 14 12 0 29417472 25214976 | 2 4202496
driver 15 12 0 1710 156 | 3 1554
magic 25 25 0 600 600 | 0 0
maplist 28 24 0 2240 1920 | 4 320
vmalist 546 516 0 13104 12384 | 30 720
buflist 192076 190211 0 23102248 22825320 | 1865 276928
files 174 168 0 56376 54432 | 6 1944
contexts 19 18 0 688 624 | 1 64
hwcontext 149 143 0 1220608 1171456 | 6 49152



which tells me the driver can darned well map my entire system memory if it wants (or at the very least knows what I have to map)

and /proc/dri/0/vm (excellent point of reference for what its actually doing right now)



offset size type flag handle mtrr map_count

0xffffc200012af000 0x00002000 SHM 0x20 0xffffc200012af000 none 3
0xd0000000 0x08000000 FB 0x00 0x00000000 3 2
0xf9000000 0x00010000 REG 0x00 0xffffc200012e0000 none 2
0xffff81003a734000 0x00001000 PCIB 0x00 0xffff81003a734000 none 3
0xf0001000 0x00100000 AGPB 0x00 0xffffc20001300000 none 3
0xf0101000 0x00640000 AGPB 0x00 0x00000000 none 3
0xffffc20001401000 0x00400000 SHM 0x00 0xffffc20001401000 none 0
0xd0000000 0x00715000 LFBB 0x00 0x00000000 none 1
0xd0715000 0x00514000 LFBB 0x00 0x00000000 none 2
0xd7aca000 0x00536000 LFBB 0x00 0x00000000 none 2
0x19b14000 0x00001000 CTX 0x01 0xffff810019b14000 none 0
0xd0c29000 0x00004000 LFBB 0x00 0x00000000 none 1
0xd0c2d000 0x00001000 LFBB 0x00 0x00000000 none 1
0xd0c2e000 0x00001000 LFBB 0x00 0x00000000 none 1
0x1b422000 0x00001000 CTX 0x01 0xffff81001b422000 none 0
0xf0741000 0x00170000 AGPB 0x00 0x00000000 none 1
0x253aa000 0x00001000 CTX 0x01 0xffff8100253aa000 none 0
0xf08b1000 0x00170000 AGPB



I very much suspect that if I were to play with the allocations in vm I could get the addition to match the LFB in the dmesg entry

And I can map the contents of /proc/dri/0/vm against /proc/mtrr and it all adds up too.

[time2IPL]

Larry,

The aperture size shouldn't cause the DRI issues you are experiencing.

I'm still uncertain as to why that setting is even there; I thought it was specific to AGP cards && resulted in the setting aside of a "memory window" in "regular" RAM for memory-mapped I/O involving the video card; I didn't realize PCI-e used a similar scheme - actually, I'm still not sure if / that it does.

The lines I was thinking along - and this may be completely wrong; I have nothing other than a vague suspicion to support it - is that the presence of the memory window (aperature), combined with this motherboard's on-board graphics (GeForce 6100; chipset == nForce 430), might be confusing newer versions of the driver that are trying to contend with hybrid PCI-e + AGP cards. Call it a sneaking suspicion; I couldn't figure out what had changed that would have affected me between driver versions, and then that occurred to me as a possibility. Like I said, I can't confirm or even offer much in support; it would make some sense, though.

From Alistair's post:

I'm running an nforce2 chipset and an amd64 (64bit) installation, the bios on this motherboard ***does not have*** a GART apeture modification setting.
This is a 939 pin socket AMD 64 (single core).

So, Alistair, you have a "real" 8X AGP board that doesn't have an AGP aperature setting; interesting... Besides that and PCI-e, the other main differences between our setups is nForce 430 (mine) vs nForce2 && am2; also, my machine is dual-core. All of which shouldn't add up to a hill of beans. It's not SMP that's the problem; even with a kernel without SMP support, I get the exact same thing when I type "startx".

I'm also seeing the same thing you are with respect to the amount of memory fglrx reports for my card:

(--) fglrx(0): VideoRAM: 262144 kByte, Type: DDR2

for a 512Mb card.


I left a message this morning with AMD, and am waiting on hearing back from them since it seems a number of people with PCI-E GPU -> AGP interface cards are running into problems.


Thanks. I think part of the problem to date has been that they haven't believed there were any problems other than "failure to read the (non-existant) FM". Hopefully, your intervention will help.


Though 8.32 is working for you, have you tried upgrading your kernel or updating any other packages?
No problems there to speak of; my "daily driver" is running kernel 2.6.20-1.2948.ljm (the suffix == my initials), all of the official RedHat / Fedora RPMs on the system are current (give or take a day or two, anyway). I've built & installed mplayer && mplayerplug-in, VLC, OGLE, etc.; no issues building or running any of them. Google Earth and Celestia run terrifically. Have full browser integration going w/ Acrobat Reader, FP9 - even RP10 support (though I generally use mplayerplug-in in lieu of it). No issues running VMWare, WINE, vncviewer... No problems with the ATI driver until the kernel went to 2.6.20, at which point, it wouldn't compile; so, I patched the driver, and once I was back up and running, discovered that you had already done the same (eg., it finally occurred to me to check the ATI site for an updated driver). Oops.

When I first built this system I was actually amazed that everything went together as smoothly as it did; everthing on the motherboard worked, including the board's integraged graphics. No problems with any of the device drivers I've written, either (including one for a wireless NIC). I actually remember being amazed at how simply & smoothly the initial setup of the X1600 went, having fought with other, older versions of the ATI driver; the current driver when I bought the card was 8.31.5, one version prior to what I'm using now.


I would also suggest upgrading to 8.37 once available to see if the issue can be reproduced there.

I'll definitely do that; if the problem is even along the lines of what I'm thinking that it might be, then the problem might very well go away...

At this point, I'm guessing I've hit the point where we're "in the dark", huh? I was afraid of that; hopefully, ATI will open source the driver and that'll be that; until then, I'll keep trying whatever they put out and hope that it fixes things, if I keep this card; I'll wait until the 8.37 driver is out, and I really hope that fixes things; if it doesn't, I'm going to have to go with a diferent card (sigh; yet even more money out the window...)

Thanks for your help; if I ever do resolve this I'll be sure to let y'all know what the problem and fix were.

- Larry


it will end up both documented and

[Michael]

At this point, I'm guessing I've hit the point where we're "in the dark", huh? I was afraid of that; hopefully, ATI will open source the driver and that'll be that; until then, I'll keep trying whatever they put out and hope that it fixes things, if I keep this card; I'll wait until the 8.37 driver is out, and I really hope that fixes things; if it doesn't, I'm going to have to go with a diferent card (sigh; yet even more money out the window...

At least you won't need to wait long for 8.37. The end of the month is near :)

[time2IPL]

As you may have already guessed, I can't seem to stop thinking about this (which is about par for the course)...

Larry
Just checked on my running (working) agp card -

...


agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[fglrx] AGP enabled, AgpCommand = 0x1f004312 (selected caps)
[fglrx] total GART = 134217728
[fglrx] free GART = 118222848
[fglrx] max single GART = 118222848
[fglrx] total LFB = 134217728
[fglrx] free LFB = 116002816
[fglrx] max single LFB = 116002816
[fglrx] total Inv = 134217728
[fglrx] free Inv = 134217728
[fglrx] max single Inv = 134217728
[fglrx] total TIM = 0



You're right, 128Mb is a reasonable default, and would seem to make sense in your case; if you look at the figures fglrx left in my dmesg, though (BTW, what I meant by "I have no idea what they mean" is "they're so far off what I would expect that I can't make sense of them"):


[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 250081280
[fglrx] max single LFB = 250081280
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0


then, following that same logic would suggest (at least) two things:

0. That the driver is treating a PCI-e card's entire RAM as its GART;
to me, that suggests that the driver is assuming that every bit of
that memory is permanently mapped in and addressable; no "sliding
aperature", etc.; and,

1. the driver isn't using the aperature size setting at all when it's
dealing with a PCI-e card; that setting is, apparently,
effectively meaningless to the driver.

Sound realistic? See anything I'm missing?

The next part is interesting to me for two reasons; when X dies, that's the last thing that makes it into Xorg.0.log:

(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.36.5
ABI class: X.Org Server Extension, version 0.3

it doesn't matter if I'm running x86_64 or i386 32-bit; the log file ends at exactly the same place. Which pretty much screams "architectural issue" (eg., driver isn't liking something on my motherboard) to me...

Also, it's usually followed by

(--) fglrx(0): VideoRAM: 262144 kByte, Type: DDR2
(II) fglrx(0): PCIE card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)


It'd be interesting to know if fglrxdrm died while attempting to figure out how much memory was on the card; that would suggest a sparse vs. flat / NUMA vs "normal" / etc. issue - or, at least, some sort of memory access issue; from the way utilization shoots up it looks more like a contention issue of some sort, maybe even deadlock.




(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.35.5
ABI class: X.Org Server Extension, version 0.3
(--) fglrx(0): VideoRAM: 131072 kByte, Type: DDR SGRAM / SDRAM
(II) fglrx(0): AGP card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)


Which isn't quite right either, since my card clearly has 256Mb on board, but it appears to be split 50/50 for the two heads.


I'm ony getting half my RAM reported too, and I'm definitely not running in dual-head mode; I don't know what's going on there. Maybe it's nothing more than a bug in libfglrxdrm.



... one interesting table I've found along my travels with ATI products is in

/proc/dri/0/mem

...



I see what you're saying; that does make sense. From the looks of it, the driver is doing it's own memory management on top of what the kernel provides; I vaguely remember hearing something to the effect of the driver was capable of that, but for whatever reason, that never stuck.

Since it is, it seems even more possible that if the driver was being run on an architecture with, say, NUMA support, or encountered an unusual memory layout, or both, that that part of it might run into some "issues". Which, the more I think about it, is what it appears is going on here...

Unfortunately, though, at this point in history, I can't test any of this and it'll have to remain pure speculation for the time being; perhaps someday...

If nothing else, as Michael noted, the end of the month is rapidly approaching, and as we're all far too well aware, there's a whole lot that can change in a couple of hours, let alone ten days.

- Larry

[Michael]

Well, it looks like this month's driver may be a late bloomer... :(

[yoshi314]

huh? what's that supposed to mean?

[sundown]

I guess it means it could be May 30th when it comes out or it could be any other day before that.
But hey, look on the bight side... Should it be postponed for next month, we might get two releases in June. This should be cool.

[yoshi314]

not really. but it would give developers more time to improve the driver.

i hate 8.36 driver for being released in half-finished state (well, at least i have that impression) just because there has to be 1 release per month.

i'd rather have ati release new driver with each development `milestone`, so to speak - that means after something new is introduced AND completely implemented.

or when new kernel/x.org comes out to sort out the compatibility issues.

[Michael]

not really. but it would give developers more time to improve the driver.

i hate 8.36 driver for being released in half-finished state (well, at least i have that impression) just because there has to be 1 release per month.

i'd rather have ati release new driver with each development `milestone`, so to speak - that means after something new is introduced AND completely implemented.

or when new kernel/x.org comes out to sort out the compatibility issues.

More time this month really doesn't give more time to the engineers for development. The 8.37 driver has been out of development stage for a month now.

This will all be covered in the upcoming development cycle article.

[yoshi314]

More time this month really doesn't give more time to the engineers for development. but it usually allows developers to code something that takes more than, say 2 or 3 weeks of development without leaving it unfinished in the driver.
that could be resolved by using a second development branch, but i doubt that the shortage of ati linux driver developers permits that.

[Michael]

but it usually allows developers to code something that takes more than, say 2 or 3 weeks of development without leaving it unfinished in the driver.
that could be resolved by using a second development branch, but i doubt that the shortage of ati linux driver developers permits that.


You'll see when the article come out, it's not exactly like that.

[time2IPL]

Well, it looks like this month's driver may be a late bloomer... :(

Looking forward to your article; I think a lot of people don't understand what's involved in the development cycle for any software product for medium to large scale companies, or how different it is from the way things are in their own worlds...

Heard anything more on the open-sourcing of the driver code or no? At this point, that's the highest thing on my list (read: at this point, I just want to fix the thing and go on about my merry way).

If it's not something that's going to be happening soon, do you know if they have a "developer program", public beta, etc.? I didn't see anything either way on the ATI web site regarding public betas (though I may well have been looking in the wrong place).

- Larry

[Michael]

Heard anything more on the open-sourcing of the driver code or no? At this point, that's the highest thing on my list (read: at this point, I just want to fix the thing and go on about my merry way).

Hope to have an article on that soon... ideally.

AMD maintains a closed beta program -- I do share some details about that in the development article.

[time2IPL]

Addendum to last - uh, that means that, in all likelihood, unless Fedora 7 slips - or the project decides to switch X servers at the last minute - no R500 or R600 card will work with anything but the VESA driver w F7, right?

Does anyone know for certain that the only problem / incompatibility between the current driver(s) and the Fedora 7 Xorg server is the version string?

- Larry

[Michael]

Does anyone know for certain that the only problem / incompatibility between the current driver(s) and the Fedora 7 Xorg server is the version string?

There might be some issues with F7 x86_64 and fglrx, as when working on the packaging scripts I ran into a few crashes, but last I tried recently with F7 and 32-bit it had worked.

[d2kx]

There are already release candidates for the 8.38 driver for windows... too bad no one leaks linux drivers :)

8.37 is coming later today (in 4 hours) or tomorrow (in 28 hours).

[Michael]

8.37 is coming later today (in 4 hours) or tomorrow (in 28 hours).

Who says that?

[d2kx]

It normaly ever comes on wednesday or thursday, and it ever comes at this time and they most likely don't release a driver on the 30th or 31th.

[danielpugh]

desperate to get 8.37.x for fedora - is there any news of even an approximate date - looking on the website 5 times a day is a pain.

If there was a way of knowing that it wont be at least for a couple of weeks my sanity might be saved. I am guessing this might be covered in your forthcoming article?

[Michael]

desperate to get 8.37.x for fedora - is there any news of even an approximate date - looking on the website 5 times a day is a pain.

If there was a way of knowing that it wont be at least for a couple of weeks my sanity might be saved. I am guessing this might be covered in your forthcoming article?

Check back before the release of Fedora on Phoronix and it will be answered.

AMD is known to release their drivers on Wednesdays... there is one more Wednesday left in the month ;)

[danielpugh]

cool, that helps. its the only thing not working (including wireless and fingerprint reader on my laptop, frustrating after using feisty fawn).

thanks very much, and fingers crossed for next week

[time2IPL]

There might be some issues with F7 x86_64 and fglrx, as when working on the packaging scripts I ran into a few crashes, but last I tried recently with F7 and 32-bit it had worked.

Sorry for having gotten completely lost here - the last I tried it, F7 && fglrx == no workee due to F7's Xorg returning a version of (I think) 1.3.something as opposed to the 7.2.whatever that the driver was expecting.

How the heck did you get it to work; did you have to downgrade the X server, or ??

Thanks,
Larry

[Michael]

Sorry for having gotten completely lost here - the last I tried it, F7 && fglrx == no workee due to F7's Xorg returning a version of (I think) 1.3.something as opposed to the 7.2.whatever that the driver was expecting.

How the heck did you get it to work; did you have to downgrade the X server, or ??

Thanks,
Larry

I am the Fedora fglrx maintainer, I was using 8.37. Check your PMs.

[slacker]

is there any way to solve the video playback problem with 8.36?
Beside waiting for 8.37 :)

[yoshi314]

going back to 8.35 is what i did.

[Michael]

There might be some issues with F7 x86_64 and fglrx, as when working on the packaging scripts I ran into a few crashes, but last I tried recently with F7 and 32-bit it had worked.

Inside the blob are some more issues now with i386... ugh. The issues I originally experienced on x86_64 seem to effect i386 now. Unfortunately the problem is tracing back to inside the binary blob. I'll try it once again when F7 final is out.

[Alistair]

Just want to fill out the details on *how I got my ATI X1650Pro AGP card working *

I've update the bios to latest on the motherboard -- a good thing as I now can see both cores on my athlon 64 *woot*

Chasing around the one path that left me feeling warm and fuzzy was memory allocation.
I found 'no more mtrrs' errors on occaisions in the logs, and I noted that DRI would actually start -but teh screen would go black appearing to hang, and trying to kill the X server in that state inevitably lead to hard lock.

1) ATI Radeon X1650Pro (ati branded box)
2) 2*256Mb Heads
3) Gigabyte GA-K8NSC board
4) 1.5Gb DDR(single channel atm)
5) AMD Athlon 64 X2 3800

Bios on motherboard to F8 version - brought up second core on the CPU .. presented memory errors on two boots with AGP GART set to 64Mb and 128Mb in the BIOS.
Was able to boot several times with 128Mb AGP GART size set, bring X up in NoDRI "yes" mode -
I was still logging "no more mtrrs" messages in dmesg. Noted that **none** of the memory allocations in /proc/mtrr lined up - it looked like it was splitting my main ram to two allocations, and completely misreading the video card.

many many many reboots later I now have this

512MB AGP GART set in BIOS, *** the kicker here, was to add the feature to enable >4Gb ram on the motherboard. This closed up the MTRR allocation for my ram to ONE line.
in GRUB boot line video=vesa,ywrap,mtrr,vram:512 vga=791
in xorg.conf Option "MaxGARTSize" "512"
also in xorg.conf Option "NoDRI" "No"

WOOT!
for the record, this is all on the ati 8.37.6 drivers... but if wow behaves like this after I rebuild wine I'm gonna roll back.