Unreleased ATI Catalyst Driver Appears In Ubuntu

[bridgman]

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.

[Dinth]

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.

[octoberblu3]

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.

[kensai]

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.

[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.

[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,.

[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.

[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.

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

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.