Unreleased ATI Catalyst Driver Appears In Ubuntu [Archive]

View Full Version : Unreleased ATI Catalyst Driver Appears In Ubuntu

phoronix

03-17-2009, 10:50 PM

Phoronix: Unreleased ATI Catalyst Driver Appears In Ubuntu

Last year when Ubuntu 8.10 was released it had shipped with an unpublished ATI Catalyst driver since the proprietary ATI drivers available to the public were not compatible with X Server 1.5, which was used by this Ubuntu release. Now with Ubuntu 9.04 coming around the corner and the ATI Catalyst driver lacking X Server 1.6 support, we have run into a similar situation. Canonical's Bryce Harrington has pushed a new unreleased ATI Catalyst driver into the Ubuntu 9.04 repository, which is compatible with X Server 1.6...

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

rotarychainsaw

03-17-2009, 11:18 PM

Guess that means I can finally try out Jaunty!

refugeer

03-18-2009, 12:48 AM

My X1600 ! Sigh! :(:(:(:(

hubick

03-18-2009, 02:22 AM

GreatWalrus

03-18-2009, 02:31 AM

My X1600 ! Sigh! :(:(:(:(
I'm with ya man... Stinks, but at least the open source ATI driver is looking promising.

ernstp

03-18-2009, 04:00 AM

I hate these back room deals where some people get access to working code and others don't. Crap like this reminds me of the reasons I switched to Linux and Free Software in the first place. On behalf of all non-Ubuntu users, ATI can take their closed binary drivers and shove it :P

Everyone has access to it of cource! You should thank Ubuntu for getting out so everyone can use it!
https://launchpad.net/ubuntu/jaunty/+source/fglrx-installer/2:8.600-0ubuntu1/+files/fglrx-installer_8.600.orig.tar.gz

ernstp

03-18-2009, 04:02 AM

do not be surprised if it happens to "disappear" from the Jaunty repository very soon.

I don't see any reason write that... of cource it won't disappear! Stupid conspiracy theory. :-P

Qaridarium

03-18-2009, 04:54 AM

I hate these back room deals where some people get access to working code and others don't. Crap like this reminds me of the reasons I switched to Linux and Free Software in the first place. On behalf of all non-Ubuntu users, ATI can take their closed binary drivers and shove it :P

come one.. a version of this driver is leaket!

1 week ago!

But this is the first version with xserver 1,6 support!

d2kx

03-18-2009, 05:33 AM

Composite / KWin4 desktop effects do not work for me (blackscreen, don't crashes however), but the overall 2D performance has improved a lot for me, in gtkperf, Firefox scrolling and Qt4-apps scrolling :)

Louise

03-18-2009, 06:03 AM

...since that support has been dropped beginning with Catalyst 9.3.
I think it is so unfair to AMD to say that it is dropped. They just moved R300-R500 support from Catalyst to open source.

So please show AMD some respect and don't say they dropped R300-R500 support!

Dropping is not supporting at all.

[Knuckles]

03-18-2009, 06:38 AM

So since the driver for X Server 1.6 is the future Catalyst 9.4, it pretty much confirms that Catalyst 9.3 will not support X Server 1.6, making it instantly useless for all upcoming distros?

I think AMD should AT LEAST provide X Server 1.6 support for 9.3...

TheK

03-18-2009, 07:34 AM

Interesting performance results on jaunty now:

UT2004: from 60 to about 75 fps.
glxgears: from 10k to 1k fps.
...I guess, the first is an improvement in the driver code; the second a better power management? The only thing, I still miss is the hardware sensor information in the control panel, as the Windows version has :)

nanonyme

03-18-2009, 07:36 AM

Everyone has access to it of cource! You should thank Ubuntu for getting out so everyone can use it!
https://launchpad.net/ubuntu/jaunty/+source/fglrx-installer/2:8.600-0ubuntu1/+files/fglrx-installer_8.600.orig.tar.gz
Looks like yet another fglrx installer ripped apart by helpful Ubuntu developers.

d2kx

03-18-2009, 07:44 AM

This X Server 1.6 supportive driver is not compatible with R300-500 graphics processors, since that support has been dropped beginning with Catalyst 9.3.

This sounds like Catalyst 9.3 wouldn't support R3xx-R5xx, which it does in reality.

jbrown96

03-18-2009, 10:17 AM

rbmorse

03-18-2009, 04:41 PM

I'm a Ubuntu user and I don't have a problem with it.

This version of FGLRX is still the same old proprietary code it has always been, all Bryce did was put a wrapper (open) around it.

Why shouldn't AMD give a beta version of their as of yet unreleased development driver to the largest and most popular desktop Linux for testing with their as of yet unreleased development next version? Is not the additional testing and exposure a good thing?

To me...this is progress!.

DarkFoss

03-18-2009, 05:25 PM

Why stop with Ubuntu..why shouldn't Fedora Suse Mandriva have the opportunity to test the driver swith their pre-releases ?

Mandriva 2009.1 is already at Rc1 and is due out next month.

bridgman

03-18-2009, 05:30 PM

tuke81

03-18-2009, 05:42 PM

Umm is this driver same 9.4? I thought that it's still under NDA, hopefully they have official permission to share it, and if not hopefully AMD does not make a big number of it.

bommelid

03-18-2009, 06:04 PM

Is this release for X server 1.6 only or can it be installed for 1.5 (ubuntu 8.10 intrepid) too?

DarkFoss

03-18-2009, 06:28 PM

As far as I know all those distros have access to pre-release drivers already through the beta program.

None of those distros *ship* binary drivers though, do they ? I think that's the essential difference here.

Mandriva usually provides several flavors of One cd's for beginners with the option to install live and configure their cards with the proprietary drivers.They also provide the same option for Powerpack subscribers..

Since cooker is using both kernel 2.6.29 and Xorg 1.6 I doubt any of next months releases will ship with an ATI(proprietary) driver..Most likely it will be available a day or 2 after AMD officially releases the 9.4's as an update.I've seen the kernel patches in Phorogit..

Legacy owners shouldn't be too bad off with the open driver..on my x800pro I was able to run UT2k4 and get over 30fps on some maps as long as they had fog like Tokera Forest.. other maps were fairly dismal at 10 fps and under.

I'm just happy to know that at least internally someone's is testing it out at Mandriva. I'd hate to have to wait until June or so to enjoy whats shaping up to be a good release.

kensai

03-19-2009, 11:53 AM

This driver is performing well, I think this is the best ATI driver I have used so far. Hope this is a sing of improvement from the decision of dropping old chips support from the catalyst driver. At least we don't need the symlink to /usr/lib64 anymore. And my performance have improved considerably. For the first time I'll say, good job AMD, and keep improving, please try hard to.

DestroyFX

03-19-2009, 12:22 PM

I made an ebuild in the gentoo-quebec overlay for Gentoo Linux.

This stuff compile and install but I have not tested them because i'm at work.

JGC_

03-20-2009, 06:13 AM

As far as I know all those distros have access to pre-release drivers already through the beta program.

None of those distros *ship* binary drivers though, do they ? I think that's the essential difference here.

This driver was not announced on the beta program, it just appeared in Ubuntu's repositories, just like the previous Ubuntu release when xorg-server 1.5 was shipped.
Besides not getting drivers via the beta program, there's an agreement you'll have to sign to join this program. The agreement contains something about not leaking prerelease drivers.

Archlinux used to ship binary drivers for both Nvidia and AMD, but as AMD doesn't take distributions other than Ubuntu serious, we decided to drop it.

bridgman

03-20-2009, 08:29 AM

Ahh, sorry... we were talking about two slightly different things. I didn't consider this specific driver a pre-release since AFAIK it was targetted for Jaunty rather than being a beta release of a regular Catalyst driver. We do the same with some OEMs when they pre-load Linux on their products, when their schedules don't quite line up withour regular release schedules.

I agree that is a semantic nuance, but it is what I was thinking when I made that last post.

Also, Ubuntu is a relatively recent addition to the list of distros we work with. Until a year or so ago we primarily worked (in the sense of trying to coordinate release planning) with RHEL and SLES/SLED, since those were the primary distros used by our workstation customers. We are gradually expanding that list based on customer feedback.

kensai

03-20-2009, 04:44 PM

This is just a joke, nvidia doesn't even work side by side with any distribution (maybe they do, but doesn't come to the case) and their drivers works flawlessly in every distribution there is. Even if I go out and create a distribution right now, there is a 95% chance the nvidia driver will work. There is a far wider difference in commitment to the community and quality of releases.

The day we see AMD is serious about Linux in general and not about only less than 5 distributions, then I will personally add the drivers officially to Arch Linux.

grantek

03-20-2009, 06:23 PM

Well, you can't blame the dev team stuck with the resources they have for trying.

I don't think the binary blob will ever be good enough for Arch, so hopefully realising that, and encouraging people to use the OSS driver, will help make the binary blob obsolete sooner :)

kensai

03-20-2009, 10:04 PM

Well, you can't blame the dev team stuck with the resources they have for trying.

I don't think the binary blob will ever be good enough for Arch, so hopefully realizing that, and encouraging people to use the OSS driver, will help make the binary blob obsolete sooner :)

I blame AMD. Is not an Arch Linux situation is a situation of all the other distributions but the ones supported which are less than 5. And we have done that already, the trashy driver got removed from the official repositories, OSS drivers, are encouraged above all right now.

AMD have to provide quality drivers to their customers, period. Don't get me wrong I am a fan of AMD processors and I buy nothing more but AMD processors. I have a lot of them around, and all my machines runs on them.

bridgman

03-20-2009, 11:59 PM

I guess I don't really understand why this has to be a blame-fest in the first place. We've made no secret about being focused almost entirely on enterprise distros until fairly recently, or that we were going to be *gradually* ramping up support for consumer users and faster-moving distros. Ubuntu was next on our list because it is pretty popular both for end users and for OEM customers who preload Linux on their products. We see the preload business as being an important one not just for our own business but for the growth of Linux in general - maybe that makes us evil again, I don't know.

I have to beg out of any arguments about symlinks; I don't like them myself, but I didn't think they were regarded as such a terrible thing in the Linux world. Again, maybe I'm missing something. Either way, if you want to make a statement and say "we don't like having to symlink and we're going to stop packaging your driver until you give us a better solution for non-multilib 64-bit" that's absolutely your call.

I have a tough time with some of the comments about "no idea about what is coming"; I'm on the beta mailing list and every week I see new alpha and beta drops which tell you what will be coming down the pipe a month or two in the future. Are you saying that's not giving you enough advance warning ? Today's beta gave a pretty good idea about the features which will be released a month or so from now, for example.

As far as server 1.6 support and your decision to go ahead without waiting for Catalyst drivers, I don't see what the fuss is about. It's your call as distro developers to decide what to include, and if one of our drivers happens to be the last thing stopping you from releasing 1.6 into test then it makes perfect sense to go ahead without us (assuming it's not just a few days). I just don't understand why it has to be a big spectacle -- I would have just said "hey folks, we're going to release server 1.6 for test and not wait for the Catalyst driver this time, we think that's better".

I know that it was awkward for fast-moving distros having to deal with just the binary drivers, and that's one of the reasons we started investing in open source drivers again. I hope the situation is a lot easier for distro packagers this year -- we have working open source drivers for all of our shipping chips, and those drivers are often being used to develop the next round of kernel and x server releases. You have to admit there have been a lot of improvements on the fglrx side as well -- the long delays from new GPU release to fglrx support are gone completely, and we're supporting new X server releases a lot more quickly as well.

We haven't quite caught up yet, so when a scheduled distro release happens just before we're ready with general support we do try to work directly with the distro to get a driver in which at least has been tested on that one distro. Hopefully a few months from now that won't be necessary either, and that should start to improve the fglrx schedule fit with rolling release distros as well.

Anyways, I hope this all gets worked out. If you can look at the other improvements we have been making over the last few months and honestly say that a non-symlink solution for your 64-bit distro was a higher priority for our average user, please let me know and I'll try to change our planning process accordingly. We are trying to roll out the improvements that affect the largest number of users first but that really isn't intended as a snub against Arch or any other distro, and I'm sorry if it seems that way to you or anyone else on your team.

Dinth

03-21-2009, 04:08 AM

Oh, there is AMD developer in this thread :)
If you are writing about fglrx prorities, i want to add my two cents to discussion.
This priorities and way you work on fglrx drivers (dont misunderstand me, i think that you guys made great progress within last few months). You repair bugs one by one, when there is somewhere one large bug causing other bugs, or piece of driver needs complete rewrite. Thats somewhat silly. because now you work in this way: there was shi*ty video tearing problem year ago, so within a year you repaired one hundred video bugs, removing one hundred video tearing types (it looks so from perspective of end user, which checks all changes between driver releases), and users are still suffering from 101 video tearing type. When you should completly rewrite video part of drivers, you could do this in few months and it would be bug free, with less work from your side. The same problem is with distro support. You add support for different distros or even distro versions one by one, where you could do standards compilant driver, and update it only to new kernels and xorg versions.

Last thing i want to mention, when you are already reading this forum, is linux technologies compatability. Linux comes with many great technologies like Mesa, KMS, Gallium3d, Xv, etc. This should be absolutely priority for fglrx drivers to be compatabile with them, and not make own workarouns and solutions (like libGL now). Thats really pain in the a** for end users and propably also developers of gfx software, when users of all gfx cards use one libGL.so, except Ati users which use another libGL.so. Even xorg.conf handling in fglrx isnt really compilant with other drivers, there are problems with simplest things like setting vrefresh,.

tball

03-21-2009, 06:34 AM

Oh, there is AMD developer in this thread :)
If you are writing about fglrx prorities, i want to add my two cents to discussion.
This priorities and way you work on fglrx drivers (dont misunderstand me, i think that you guys made great progress within last few months). You repair bugs one by one, when there is somewhere one large bug causing other bugs, or piece of driver needs complete rewrite. Thats somewhat silly. because now you work in this way: there was shi*ty video tearing problem year ago, so within a year you repaired one hundred video bugs, removing one hundred video tearing types (it looks so from perspective of end user, which checks all changes between driver releases), and users are still suffering from 101 video tearing type. When you should completly rewrite video part of drivers, you could do this in few months and it would be bug free, with less work from your side. The same problem is with distro support. You add support for different distros or even distro versions one by one, where you could do standards compilant driver, and update it only to new kernels and xorg versions.

Last thing i want to mention, when you are already reading this forum, is linux technologies compatability. Linux comes with many great technologies like Mesa, KMS, Gallium3d, Xv, etc. This should be absolutely priority for fglrx drivers to be compatabile with them, and not make own workarouns and solutions (like libGL now). Thats really pain in thehttp://www.phoronix.com/forums/newreply.php?do=newreply&p=67557 a** for end users and propably also developers of gfx software, when users of all gfx cards use one libGL.so, except Ati users which use another libGL.so. Even xorg.conf handling in fglrx isnt really compilant with other drivers, there are problems with simplest things like setting vrefresh,.

Ehm isn't it nvidia, which has their own workaround implementation? Ati tries to use the existing standard implementation, but you have to understand that suck right now :-) If they used all mesa lib, they would end up having openGl 1.2 and so on. When mesa, galium3d and dri2 is getting more mature you won't be using fglrx. Then you use open source drivers like radeon :-) Sorry but I really don't see you point of view. In the statement above you got some contradictions.

kensai

03-21-2009, 09:17 AM

I have to beg out of any arguments about symlinks; I don't like them myself, but I didn't think they were regarded as such a terrible thing in the Linux world. Again, maybe I'm missing something. Either way, if you want to make a statement and say "we don't like having to symlink and we're going to stop packaging your driver until you give us a better solution for non-multilib 64-bit" that's absolutely your call.

Symlinking has miraculously been fixed in the 9.4 catalyst driver which was handled to ubuntu, and ubuntu made public, not AMD. I have to say, the 9.4 driver is going to be great, I have had a performance boost. Now that the symlinking is not needed I feel a whole lot better about the catalyst drivers, I'll wait and see how catalyst 9.4 official comes out, in concerns of stability.

But still my biggest concern now, since I see the 9.4 driver will be way better and not require a symlink, are xorg and kernel. All I want from AMD now, is to work not side by side with any distribution, just work side by side keeping up with the releases of xorg and kernel.

Having said that, and being testing the 9.4 catalyst since it was given by ubuntu, I have to say nice work, please keep improving as you have done lately, my apologize for being so harsh, but you see I had my reasons. I can't say catalyst will be put officially in Arch Linux yet, but when catalyst are prove great again I will look into them being included officially again.

octoberblu3

03-21-2009, 10:44 AM

I would just like to take a second to applaud bridgeman for coming back to this forum repeatedly to answer the numerous attacks with good information that repeatedly gets ignored.

libGL - ATI has a better one than Mesa when it comes to 3D rendering. Enterprise distros and the people that use them don't openness when it comes to rendering as quickly as possible.

Nevermind that Nvidia does this as well.

Dinth

03-21-2009, 11:24 AM

libGL - ATI has a better one than Mesa when it comes to 3D rendering. Enterprise distros and the people that use them don't openness when it comes to rendering as quickly as possible.
And completly uncompatabile with any other drivers i think? That sucks if someone wants to have installed two drivers at once, like fglrx and radeonhd.

bridgman

03-21-2009, 12:48 PM

You repair bugs one by one, when there is somewhere one large bug causing other bugs, or piece of driver needs complete rewrite. Thats somewhat silly. because now you work in this way: there was shi*ty video tearing problem year ago, so within a year you repaired one hundred video bugs, removing one hundred video tearing types (it looks so from perspective of end user, which checks all changes between driver releases), and users are still suffering from 101 video tearing type.

Actually the "tearing" issues were in different parts of the code, and all of them had to be addressed in order to give decent video playback. The earlier issues were related to the way that video was rendered to the screen (some diagonal artifacts were introduced there, which had to be fixed), while the remaining issues are related to lack of sync-to-vblank capability in Xv. That's not a bug as much as a missing feature which needs to be added.

Older GPUs had sync-to-vblank capability built into the hardware overlay. When we started moving from video overlay to textured video (overlay doesn't work with compositors) and took the dedicated video processor out of the overlay (starting with 5xx) we lost the hardware sync-to-vblank and needed to build that capability into the driver stack.

The X/DRI framework doesn't really have a mechanism for dealing with this (it does with a direct-rendering driver like OpenGL but not with an indirect-rendered one like Xv) and that is being designed into the framework now. This is another case where over-writing portions of the framework would have made our life easier, but since doing that also tends to slow down the rate at which the framework improves we over-write as little as possible and back out that code as the framework catches up.

When you should completly rewrite video part of drivers, you could do this in few months and it would be bug free, with less work from your side.

That's what we've been doing. Rewriting code doesn't make it bug free, though, it just lets you address problems which were inherent to the old design (assuming they aren't also in the new design). Rewrites also introduce new bugs, of course, although I think most of those have been found and fixed by now.

The same problem is with distro support. You add support for different distros or even distro versions one by one, where you could do standards compilant driver, and update it only to new kernels and xorg versions.

Um... no. Adding support for a distro usually involves either making our installer / packaging scripts smart enough to deal with different file locations in each distro, or changing the driver code to deal with implementation decisions made for a specific distro (see the multilib / Arch discussions as an example).

Last thing i want to mention, when you are already reading this forum, is linux technologies compatability. Linux comes with many great technologies like Mesa, KMS, Gallium3d, Xv, etc. This should be absolutely priority for fglrx drivers to be compatabile with them, and not make own workarouns and solutions (like libGL now). Thats really pain in the a** for end users and propably also developers of gfx software, when users of all gfx cards use one libGL.so, except Ati users which use another libGL.so. Even xorg.conf handling in fglrx isnt really compilant with other drivers, there are problems with simplest things like setting vrefresh,.

One important thing to understand is that these technologies tend to be implemented in proprietary drivers years before something similar becomes available in the general Linux / X framework.

Mesa is designed to be highly portable across different environments, not for ultimate performance, while fglrx is designed for maximum 3D performance. We moved the last of our OpenGL drivers over to an architecture like Gallium3D almost two years ago, around the time that Gallium3D was first announced. The proprietary drivers have had high performance memory management in the kernel for years. Again, that capability is just being added to the standard framework now in the form of GEM and TTM.

Others have already mentioned that we actually over-write *less* of the X/DRI environment than other binary drivers, not more. We do pay a price for that in terms of the extra work required to stay compatible with new kernel and X versions, but I think it's still worth the price.

Xv is an API (which we support) more than a technology. When you complain about tearing you're complaining about tearing via the Xv API.

tarzan

03-21-2009, 07:45 PM

By the way, the new driver shipped with Ubuntu is still broken for Lenovo T400 users (blank screen when logging in, machine seems to work fine). I think the last working version was 8.11? The machine features a Radeon HD 3470 gpu.

Kano

03-21-2009, 08:03 PM

nanonyme

03-22-2009, 12:04 PM

@bridgman

Is it possible to use a similar code like in the current oss drivers for xv? Because I still see tearing even with those updated fglrx drivers (and that even without compiz). I know how this looks - vdpau has got similar issues when composite is active. Maybe the fglrx dev do not look sharp enough when they test it or the test movie is in slowmotion ;)
Afaik it's like this: open drivers can't use source code from closed drivers due to NDA's and closed drivers can't use source code from open drivers due to licenses. Gotta love 'em lawyers, huh?

bridgman

03-22-2009, 12:21 PM

It's not quite that bad; open drivers have a tough time using code from closed drivers partly because the code would need to go through IP review (and we already have a lot of that in the pipe) and partly because the closed drivers are much larger so code is usually split across a half dozen different components.

Closed drivers can use code from the open drivers more easily although again the source code architecture is usually very different so you can't just plug the code in.

That said, the main reason for not using code from the open driver is that it stalls the whole stack while waiting for sync-up and as a result there are a range of higher res videos which you can play on fglrx but not the open drivers unless you turn off the syncing. I can't say "these 3 videos" because it totally depends on the system hardware, but there have been a bunch of reports like this.

The real solution is getting the stack fixed; page flip in Compiz/KDE/whatever, then flow control back up the stack so that rendering can go full speed without anything having to spin waiting for sync, with logic in the video part to double-up or skip frames as needed. For the case of a single video stream whose native frame/field rate was close to the display frequency (say 30/60 Hz video with a 60 Hz display), fine-tuning the refresh rate would also help. The current code might be a good short term fix though as long as it can be turned on and off easily.

nanonyme

03-22-2009, 02:08 PM

bridgman

03-22-2009, 02:48 PM

Fear not; there will still be a March driver. Normally we try to ship Windows and Linux Catalyst drivers off the same release, but for March we're going to use a slightly later internal release for Linux in order to pick up some Linux-specific changes.

We'll probably do the same for April, ie use a slightly later internal release for Linux drivers than for Windows to let us get the last few March changes into the April driver as well. In internal-release-speak, the March Linux driver will probably be 8.593 for Linux vs 8.592 for Windows.

The Ubuntu driver doesn't quite match any of our regular releases -- it has server 1.6 support but doesn't have all of the other changes currently in the pipe for March and April.

matt8

03-22-2009, 03:15 PM

Fear not; there will still be a March driver....

Hi.

I was wondering if the RS880 IGP chipset will support 7.1 channel LPCM over HDMI, and if so, with support for Linux. I think that was a major shortcoming from a multimedia perspective with the 790GX chipset which I currently own. Also, will TV tuning on the "All in wonder" cards be ever supported under Linux, or is that completely off the cards?

Thanks.

bridgman

03-22-2009, 04:10 PM

I was wondering if the RS880 IGP chipset will support 7.1 channel LPCM over HDMI, and if so, with support for Linux. I think that was a major shortcoming from a multimedia perspective with the 790GX chipset which I currently own.

Sorry, but I can't really talk about unreleased products. We're trying to get at least basic out-of-box support (modesetting + shadowfb) into the spring distro releases but anything more detailed will have to wait until the chip actually gets released.

Also, will TV tuning on the "All in wonder" cards be ever supported under Linux, or is that completely off the cards?

I don't think we have any plans to add that capability to the Catalyst drivers. The tuners themselves are all third party components so we wouldn't be providing programming information for those anyways. That said, the tuner vendors are usually pretty good about providing datasheets and programming info since they usually don't need to expose anything particularly secret to let you use the part.

I'm not sure about the status of capture chip support in the open drivers (the capture chip is what gets tuner output into the PC so it can be stored in a file or displayed on the screen) but will ask. If there is no support today we can look into releasing some in the future, but all the usual caveats apply (ie if we can't separate the info for normal operation from the info used for DRM-type stuff then we won't be able to release the info needed for normal operation).

rotarychainsaw

03-22-2009, 09:36 PM

Release something! I'm bored!

dgrafenhofer

03-24-2009, 01:30 PM

Is there any chance that the 9.3 or 9.4 versions of catalyst will work again for Mobility Radeon HD 3650 users?

See bugreports on launchpad:
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/314600
https://bugs.launchpad.net/fglrx/+bug/288620

Dominik

Kano

03-24-2009, 02:01 PM

Some bugs are because of the /etc/ati/amdpcsdb file which usually written on X shutdown. When you update the driver while X is running then it would not help to remove it on update as a new file is written on shutdown. That's the problem with running X -> GUI update is not always the best. At least this kind of error can be avoided when you run a script from text console - or extra tricky using nohup.

dgrafenhofer

03-24-2009, 02:30 PM

Some bugs are because of the /etc/ati/amdpcsdb file which usually written on X shutdown. ... That's the problem with running X -> GUI update is not always the best.

I tried to install with and without the X-server running. Unfortunately this did not solve the crash on the startup of X.

Dominik

Kano

03-24-2009, 02:36 PM

It is not removed the old file by default. Did you really use

/etc/init.d/atieventsd stop
/etc/init.d/gdm stop

rmmod fglrx

or similar and then

rm -rf /etc/ati

before installing new driver?

dgrafenhofer

03-24-2009, 02:58 PM

Did you really use
...
before installing new driver?

Strictly speaking "no", but in effect I guess "yes":

On opensuse 11.1 I installed the 8.12 on toa clean install (without any proprietary driver). There should not be any files under /etc/ati in this situation.

On ubuntu 8.10 I called the uninstall script under /usr/share/ati and performed a reboot before installing the new driver. I also tried your install script under ubuntu (which calls "rm -rf /etc/ati").

Kano

03-24-2009, 03:01 PM

Well you have to reboot on opensuse then when you dont do

rmmod radeon drm

before starting X. Somethigs even this has problems, therefore my script has a lesser known option called -z which would require a reboot.

dgrafenhofer

03-24-2009, 03:40 PM

Well you have to reboot on opensuse then when you dont do

rmmod radeon drm

I always reboot after installing catalyst, so this should not be the issue.

Now I also tried to remove /etc/ati on opensuse before installing the 9.2 version of catalyst... still crashes...

kensai

03-25-2009, 11:12 PM

Yay!, 9.4 doesn't work with kernel 2.6.29. Huuray for AMD and their great "Linux" "support". When are you guys going to support Linux and not some distributions?

PuckPoltergeist

03-26-2009, 06:49 AM

Yay!, 9.4 doesn't work with kernel 2.6.29. Huuray for AMD and their great "Linux" "support". When are you guys going to support Linux and not some distributions?

What are you complaning about? 9.4 isn't released yet.

bridgman

03-26-2009, 07:24 AM

Yep, just to be clear, the Ubuntu driver is an early branch off what will become the 9.4 release, not the final 9.4 release itself.

Kano

03-26-2009, 07:29 AM

Did somebody ever try to play a video with a res like 1280x536 which shows about a 8 pixel green bar. xv seems to work only when the res % 16 is 0.

tball

03-26-2009, 10:11 AM

I always reboot after installing catalyst, so this should not be the issue.

Now I also tried to remove /etc/ati on opensuse before installing the 9.2 version of catalyst... still crashes...

I'm sure its trying to run your X in 8 bit, which fglrx doesn't support

Just add this to you "screen section" of fglrx:

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
DefaultDepth 24
EndSection

My X crashed also after downgrading fglrx from 9.4. It now works, becuase of the DefaultDepth 24 line.

dgrafenhofer

03-26-2009, 01:49 PM

I'm sure its trying to run your X in 8 bit, which fglrx doesn't support

Unfortunately the "DefaultDepth" is already set to 24 in my xorg.conf.

kensai

03-26-2009, 04:39 PM

What are you complaning about? 9.4 isn't released yet.

Is just I'm used to it, 9.4 will be the exact same driver ubuntu has now. Count on it. Maybe, maybe they will add kernel 2.6.29 support. But it basically is what it is now. Remember is AMD/ATI.

Wintervenom

03-26-2009, 04:57 PM

kensai

03-26-2009, 07:46 PM

Every since Catalyst 8.12, I have a problem that whenever the X server gets restarted, the system will lock up. Someone figured out that unloading and then reloading the fgrlx module before the X server is started again will fix it, and seems to be working for me. Might this be fixed in Catalyst 9.3 or 9.4?

(I have a Toshiba Satellite M305-S4830 with a Radeon 3100 and I am running Arch 64, but it does this on other Linux distros, too.)

I have restarted X once since I have 9.4, and restarted X by accident, I feared it will lockup like all catalyst drivers do, but even thought the error that gets the screen locked was there, the X server restarted fine. So hopefully this will get fixed miraculously, as always. Thats the best chance we have.

tball

03-28-2009, 12:54 PM

Is just I'm used to it, 9.4 will be the exact same driver ubuntu has now. Count on it. Maybe, maybe they will add kernel 2.6.29 support. But it basically is what it is now. Remember is AMD/ATI.

Uhm no it isn't. There is A LOT of technologies which isn't included in the ubuntu driver. Trust me, I have tried both. The now released 9.3, is much more similar to the 9.4 beta, than "9.4" from ubuntu's repo

kensai

03-28-2009, 08:27 PM

I really hope you are right, the release of 9.3 raised my hopes up, still I feel pretty bad on how they didn't added newest kernel and xorg support. Leaving all those old cards to rot if they want to play games. Is like what kind of company would do that to the users? I know who, AMD. AMD is holding the adoption of Linux from their users, which gets discontent when it just doesn't work. Nvidia users love Linux, if I hadn't be an nvidia user when I first started with Linux more than 5 years ago I wouldn't be a Linux geek now, not even a developer. But now my primary system is Linux even though I'm a network administrator for a big company. Thanks to nvidia.

I wish one day I can be happy with AMD/ATI. I'm not ready to give up yet.

tball

03-29-2009, 04:55 PM

Kano

03-29-2009, 05:00 PM

Well defining R500 cards as old is just not that easy to understand. Also Win support was not completely dropped, still 4 releases a year. Only for Linux it seems costs have to cut down to a minimum. Opensource is nice, but the speed of the current driver is far way from fglrx for games, in my opinion it is no fair replacement - only for lowend cards not used for games.

kensai

03-29-2009, 06:56 PM

Very true what Kano said. Linux is getting bad opensource drivers, that might be good for anything 3d related in about 5 years. And even not 3d related, they have a lot of 2d issues. Sow e are stuck in bad catalyst drivers with 3d support, or not that bad open source drivers with some 3d support. At least with nvidia you can go superb drivers with 3d support and all the latest technologies, and support for the latest kernel and xorg instantly even on legacy chips, or not that bad nouveau (open source) drivers with some 3d support.

And no, that is not the way Linux is meant to be played:

Linus Torvalds quote:
"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested. 99% of that I run tends to be open source, but that's _my_ choice, dammit."