Unreleased ATI Catalyst Driver Appears In Ubuntu

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

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

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

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

[tarzan]

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]

@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

[nanonyme]

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

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]

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.

Hey, don't get my hopes up too much, I might start expecting improvements.
A matter of idle pondering since no one who knows probably is allowed to say anything at this point: I sincerely hope AMD will still make a March driver release even though Ubuntu got this unreleased version of the driver. Seems Windows already got their own 9.3.

[bridgman]

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.