AMD Catalyst 9.5 Driver For Linux Released

[alexforcefive]

For those of you who saw a regression in ubuntu 9.04 (cards that used to work in 8.10 and no longer work with catalyst) ... did this fix the issue?

Thank you

Are you talking about slow resizing etc with compositing enabled? That hasn't been fixed for me with 9.5

[BlackStar]

the Composit bug,,, is an ubuntu bug in the xorg of the ubuntu 9.04

amd tried to bring composit @ 9-6 but they found a bug in ubuntu amd can't fix this!

if ubuntu fix this problem.. we will see nice composit on 9-6 catalyst.

if not... 9.10 will be the first for have real-bugfree composit.-..

belive it or not it's not my problem i don't use Composit!

Is this a reported bug? Do you have a link to the bug report in Launchpad?

[cutterjohn]

Not sure I understand what you're getting at. There is a much higher degree of per-OEM customization with mobile products, so AFAIK we normally only support the desktop parts in Catalyst Windows drivers. For laptop drivers, we normally recommend that users contact their laptop mfg to obtain the appropriate Windows drivers.

There are exceptions, of course. Since relatively few systems are sold with Linux preloaded by the OEM, we include Mobility GPU support in the Linux drivers. We also included 3xx-5xx Mobility IDs in Cat 9.3 for Windows, as part of the transition to a reduced support model.

We did periodically produce a "generic" Mobility Catalyst driver for Windows in the past; not sure what the current status of that is.

(I wrote a long reply to this, but since it's Windows cebtric decided to drop it. Anyways another bad move, but at least for the linux drivers this doesn't apply, so I'll modify the response in a feeble attempt at staying on topic.)

[bridgman]

Anyways, vendors are mostly incompetently attempting re-brands of the generic drivers anyways, and I've already noticed that some ATI/AMD re-sellers are pulling the same stunts with their desktop cards as well. Fortunately they're not very sophisticated and easily worked around, although ATI/AMD admitting this and just supporting us with standard releases would help immeasurably.

We provide the customized/branded drivers, not the board/laptop vendors. If the customizations all look the same there's a reason . We do provide API support (through ADL and its predecessors) to allow customized control panels, however, so if you see one of those that probably was developed by the OEM or board partner.

When you say "worked around" what are you actually working around, ie what do you feel you are not able to do without a workaround ?

(At least some of the desktop part guys actually design boards though after the intial chip release... they still don't do much with the software though, although I imagine that's because GPU driver software is likely arcanely complex...)

Yeah, arcanely complex is a pretty good summary. Really big *and* arcanely complex is probably better

[cutterjohn]

Oops, missed that, but anyways I wanted to stay on the linux driver topic, but as to working around it's just adding what I think is the vendor identifier signature and sometimes removing what looks to be something like the generic installer is looking for when it decides to not install. With MSI IIRC for windows there's an OEM.inf file as well as the above mentioned vendor signature. (There are several sites that automate this process of allowing the generic drivers to be installed but they mainly support ONLY the larger OEM/ODMs, e.g. ASUS and not smaller guys like MSI.)

catalyst cp looks almost identical between windows and linux, i.e. MSI driver v. generic driver. As a matter of fact the windows cp doesn't even mention MSI other than as the vendor, as do other company's similar driver GUI interfaces.

"Work around" specifically? Well modifying the generic driver to actually install since the vendor seems to be incapable of timely driver updates, but it's a chore and I haven't bothered with it yet since 8.12 for Windows seems to be mostly OK for my uses ATM,although I am hoping for PhysX and the genero version of CUDA updates(forget the name ATM since CUDA is the de facto standard_ eventually once ATI/AMD unbends a little unless nVidia attached strings to their offer unbeknownst to ordinary end users. (Quite a few other GT725 owners have already done this... no problems, better performance sometimes ... and by quite a bit with 9.3 IIRC as far as vantage and Crysis benching went. Then there's the guy tinkering with the BIOS to unlock the clocks towards desktop levels...)

[EDIT]
Oh yeah, also with MSI noone, apparently, ever explained the concept of changelogs to them. Their updates are complete mysteries, which is most annoying with their BIOS releases... zero info for their notebooks, and one or two incredibly vague comments about their motherboard BIOS updates, so I've dropped them for that alone for X58 board consideration... speaking of which that CUDA/PhysX support would go a LONG ways to making a case for CF 4770/4850s v. a GTX260 or 280...
[/EDIT]

[mtippett]

Is this a reported bug? Do you have a link to the bug report in Launchpad?

https://bugs.launchpad.net/bugs/351186

It isn't really a bug on either side.

The issue is a X patch that was originally applied to resolve an Intel corruption bug (basically copy the texture from GPU to physical memory). This is a current slow path on the proprietary driver and effectively a free operation on Intel (GPU _is_ physical memory). Apparently UXA fixes the corruption that was present in EXA, but since UXA wasn't stable for Jaunty the decision was made to enable the patch, disable UXA, and let fglrx go down a slow path.

Realistically, I doubt there was a pro-active decision to force fglrx users down the slow path, but more so a little less-than-needed regression testing when making a decision to enable the patch.

There is a link to a ppa archive with an X server without the patch, which provides a reasonable improvement. And accelerating this slow path is now a feature that needs to be added to the driver (and isn't a bug or a regression in the driver).

Regards,

Matthew

[mtippett]

Maybe you did not understand me, when you use Xserver 1.4 then the fglrx driver is a differnt one than which is installed when you have got 1.5/1.6. And when you update libdrm on that config you run into troubles.

Almost. The code that integrates with the X server ABI is different, the other HW specific code is the same. The code that integrates with the kernel module changed as of 8.60 to be common across all versions.

We are in the process of abstracting out the X server code to make things easier to maintain, but as mentioned elsewhere, we need to maintain support for multiple versions of X.

Realistically around the 8.59/8.60 timeframe we effectively completed the fork of the DRI infrastructure to suit prevent future X versions breaking us. The current MESA/glx/X/DRI/DRM code is all very tightly integrated in the upstream X server, so the experimentation/refactoring in DRI1 in preparation for support of the DRI2 kept breaking our ABI. We had to fork glx/DRI/DRM.

This really only leaves the core X interfaces as our only ABI exposure. This unfortunately means we no longer play nice with OSS drivers, but the OSS drivers were not keeping stable ABI's anyway. If we only had to support the tips of the upstream code, we may not have needed to, but we support more legacy that upstream so we made that decision.

[tarzan]

From the release notes:

Starting X with a second hotplugged display may cause segmentation fault

Will this be fixed at all? I am unable to use Catalyst for some time now since amdcccle will crash everytime when my Notebook is docked (Lenovo T400, external Screen via DVI).

[NeoBrain]

Almost. The code that integrates with the X server ABI is different, the other HW specific code is the same. The code that integrates with the kernel module changed as of 8.60 to be common across all versions.

We are in the process of abstracting out the X server code to make things easier to maintain, but as mentioned elsewhere, we need to maintain support for multiple versions of X.

Realistically around the 8.59/8.60 timeframe we effectively completed the fork of the DRI infrastructure to suit prevent future X versions breaking us. The current MESA/glx/X/DRI/DRM code is all very tightly integrated in the upstream X server, so the experimentation/refactoring in DRI1 in preparation for support of the DRI2 kept breaking our ABI. We had to fork glx/DRI/DRM.

This really only leaves the core X interfaces as our only ABI exposure. This unfortunately means we no longer play nice with OSS drivers, but the OSS drivers were not keeping stable ABI's anyway. If we only had to support the tips of the upstream code, we may not have needed to, but we support more legacy that upstream so we made that decision.

Just wondering, do you have any plans about bringing some variant of KMS support to Catalyst?

[mtippett]

Just wondering, do you have any plans about bringing some variant of KMS support to Catalyst?

There are no plans at this stage. Most people I have spoken to don't have an interest in seeing kernel messages appear on their screen. Last time I saw that in a production system was on old Sparc X Terminals.

Beyond that (which can already be achieved with a kernel based chvt + message to that console (aka the Linux BSOD)), it is about avoiding slow switches during boot and fast chvt's. We haven't seen any direct requirements for these. THe intel chvt takes a second or two, under fglrx takes about half a second.

The GEM/TTM/other parts of what people call KMS we have already had since the R6xx family was enabled.

Regards,

Matthew