Unreleased ATI Catalyst Driver Appears In Ubuntu

[kensai]

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]

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

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]

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]

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]

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]

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]

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]

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]

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.