AMD Catalyst 8.5 For Linux

[Redeeman]

i dont believe its kernel related, it is userspace definetly, the kernel problem was merely that i had to activate legacy crap, plus the fact that i had to manually modify the x86_64 code to export a symbol on 2.6.25 - meaning amd obviously has not tested this release on 2.6.25 x86_64.

i dont have concerns per se, i have PROBLEMS, aka, the thing isnt working.

It is a HD3450, and well.. it starts my screen in unusable resolution (which then when i kill X, corrupts my linux console). Every application segfaults at ~exit time. glxinfo lists no dri. opengl with world of warcraft is COMPLETELY broken, doesent evne start, with dx mode, i get ~1-3 fps at the login screen, this is speeds of mesa.. neverball however runs as it should with accelerated graphics, but who knows, maybe mesa is doing this aswell?

i am _100%_ certain i have installed properly, this is simply buggy driver..

bridgman:
we have argued before, but im not gonna continue that here, i have 1 simple question, these issues i have, are these something that can be correctly in the extremely near future, or should i just forget about it and smash the card away in a server or something? (i did kindof expect to have to do this, i just wanted to give AMD a chance to proove it could let me use their hardware)

[oblivious_maximus]

Yeah, I think I get the message

Yeah sorry, I really was flabbergasted.

Serious question though; if most of your Linux sales were in the commercial workstation market, and if most of those customers ran SLED and RHEL, and if the distro most used by the rest of your customers (in the consumer market) was Ubuntu...

... what would you test on ? Do you think testing on Debian would make more users happy than testing on Ubuntu, for example ?

I think possibly, yes. Maybe I'm mistaken, but wouldn't a majority of the testing done on Debian be applicable to Ubuntu as well? I know Canonical makes a lot of changes but they still get all(nearly all?) their packages from sid, and most of Canonical's changes eventually make it back into Debian. And of course there are more distros based on Debian than just Ubuntu - but there's also starting to be a few distros based on Ubuntu now too. I guess I'd be a lot more happy about the situation if you tested on at least one Debian-based distro. If that was Ubuntu I expect it would still be pretty relevant to Debian. IDK though, someone who knows more about the specific differences between Ubuntu and Debian could probably better estimate the value to Debian users of testing on Ubuntu, and vice versa. But like I said, I think it's pretty imperative that AMD is testing on at least one Debian-based distro.

Unless Asus and their disappearing-from-the-M3A-bios-memory-remap-option is to blame for my issues, it now seems pretty clear that my HD3650 has been gathering dust for months because AMD has completely ignored an entire, major category of Linux distribution. For example, the bug in authatieventsd.sh where it doesn't point to /var/run/xauth - that's been known since at least 8-3, but with both 8-4 and 8-5 I had to manually patch it. If AMD was testing on a Debian(-based) system, this likely never would have been a bug to begin with (I assume).

if most of your Linux sales were in the commercial workstation market, and if most of those customers ran SLED and RHEL...

My problem with this statement is this - what about the individual customers who also spend their hard earned cash on your products? Certainly none of us spend in one go what the corporations running SLED and Red Hat do, but we are still your customers, despite the fact that we are an extremely difficult bunch to quanitfy*.

It seems to me that Red Hat, SUSE and Debian are the 3 main distros from which the majority of other distros are based. Only testing on 2 out of 3 just doesn't make any sense to me, regardless of what the majority of corporate customers use. It's like a 2-legged tripod... or something, I'm obviously not very good with analogies.

In general, though, fglrx is aimed primarily at the distros more likely to appear in a commercial or consumer environment, and the open source drivers are aimed at the faster-moving "upstream" distros.

I have problems with that as well. I absolutely, wholeheartedly, unequivocally support your efforts releasing docs and fostering the open drivers - that's the main reason I bought an ATI card I didn't actually require. However until such a time as either of these drivers has something resembling feature parity (notwithstanding the DRM features [not the Direct Rendering Manager] which are likely to remain fglrx-only), fglrx should be aimed at anyone who has purchased your hardware(any which fglrx supports) with the intention of using it on Linux. Anyone with an R600 card and problems with fglrx is bascially S.O.L. right now. It would seem doubly so if they use a Debian-based distro.


---
I'm tempted to offer up the spare M3A motherboard (AMD770/SB600) I have if it might expedite getting a Debian-based test box up and running (and hopefully finding my issue's remedy). I don't have any of the other necessary parts for a system spare though... If your testing systems are somewhere other than Markham though I don't think it'll happen.

*I had an idea while writing this post, it's something that would require quite a bit of work though I expect. Anyway here it is: Inside the boxes of ATI cards (channel partners would have to participate also) there could be a slip of paper asking "Do you intend to use this video card under a Linux-based operating system? If so please go to www.amd.com/linuxcounter and let us know to help us make our Linux software as excellent as it can be." At the website would be a short form where customers could enter the product they bought and its serial number(so as to prevent abuse), and the distribution they use. This could help AMD generate some hard data on who's using what and in what numbers. The card-in-the-box isn't strictly necessary either, as long as people know about the site and to submit their info. Anyway, just an idea.


I hope my frustration hasn't given the wrong impression. Despite it, I'm still a big supporter of AMD (always have been) and the work you cats are doing to provide an open driver, and the interaction/support you, specifically, provide here, bridgman. From what I've seen at nvnews.net while looking for solutions to the less-major issues I have with my Nvidia card, the Nvidia staff there don't do much but make excuses, and sow misinformation. Apart from taking bug reports that is (they're not all bad I guess). Dealing with the same issue driver after driver and reading about many other people doing the same with other issues is a recipe for aggravation though. Anyhow, I think I've posted more than enough here, thanks for being here to hear what we have to say bridgman, I'd be a lot more frustrated were it not for your insights into what goes on behind the scenes.

edit: sorry for rambling a lot.

[Redeeman]

the nvidia drivers works equally well in all distributions.. in other words, is AMD incapable of atleast matching nvidias level of software (damn, never thought id have this word in an nvidia sentence) quality?

[bridgman]

It is a HD3450, and well.. it starts my screen in unusable resolution (which then when i kill X, corrupts my linux console).

This sounds odd. Is there a Bugzilla ticket open for this, with log ? Is this specific to 8.5 or did it happen with previous releases as well ?

Every application segfaults at ~exit time.

Is this under Wine/Cedega/whatever or native ? Any other info we could use to understand what is happening ?

glxinfo lists no dri.

OK, something is definitely installed wrong then. Can you paste a log somewhere, ideally Bugzilla ?

opengl with world of warcraft is COMPLETELY broken, doesent evne start, with dx mode, i get ~1-3 fps at the login screen, this is speeds of mesa.. neverball however runs as it should with accelerated graphics, but who knows, maybe mesa is doing this aswell?

Yeah, until you get DRI=yes it's not worth going any further.

i am _100%_ certain i have installed properly, this is simply buggy driver..

I'm sure you followed the proper steps, but it doesn't sound like the installation is right for your specific system. If you are running WOW over Wine (are you ?) on Debian or Ubuntu there seem to be strong recommendations for installing via Envy. Not sure if it actually sets something different or is just less likely to fsck up, but it seems to be a common recommendation.

EDIT -- there also seem to be some horror stories associated with Envy, so not sure who to believe here

I remember hearing that there was a last minute fix for either the Ubuntu or Debian packaging scripts which didn't quite make the release; not sure what the details are but will try to find out.

bridgman: we have argued before, but im not gonna continue that here,

Have we actually argued about anything other than DRM ? DRM is like politics, you're expected to argue about it

i have 1 simple question, these issues i have, are these something that can be correctly in the extremely near future, or should i just forget about it and smash the card away in a server or something? (i did kindof expect to have to do this, i just wanted to give AMD a chance to proove it could let me use their hardware)

The problems I understand don't happen on other systems with the same card and driver, but they are happening on your system, so we need to understand how to reproduce them in house so we can sic a developer on them.

[chikazuku]

Just tried this driver on my fresh Gentoo-install: it changes my screen into a fireworks display at X.org startup, stopping at some fire-red which makes you think the device is completely demolished like when the chip's burned.

The opensourcedriver manages 2D and XVideo fine, but 3D is limited to glxgears or it'll bring down the system.

Xpress 200M owners are presumable sentenced to hell for the rest of the time they use their laptops.

[bridgman]

Yeah sorry, I really was flabbergasted.I think possibly, yes. Maybe I'm mistaken, but wouldn't a majority of the testing done on Debian be applicable to Ubuntu as well? I know Canonical makes a lot of changes but they still get all(nearly all?) their packages from sid, and most of Canonical's changes eventually make it back into Debian. And of course there are more distros based on Debian than just Ubuntu - but there's also starting to be a few distros based on Ubuntu now too. I guess I'd be a lot more happy about the situation if you tested on at least one Debian-based distro. If that was Ubuntu I expect it would still be pretty relevant to Debian. IDK though, someone who knows more about the specific differences between Ubuntu and Debian could probably better estimate the value to Debian users of testing on Ubuntu, and vice versa. But like I said, I think it's pretty imperative that AMD is testing on at least one Debian-based distro.

Agreed. When we were completely workstation focused it wasn't such an issue (according to our info RHEL and SLED make up 135% of the workstation market ) but now that we're focusing on consumer use as well we have to include a Debian-based system. That user stats seem to be so overwhelmingly biased towards Ubuntu that we figured Ubuntu testing would actually make for more happy users than Debian.

Unless Asus and their disappearing-from-the-M3A-bios-memory-remap-option is to blame for my issues, it now seems pretty clear that my HD3650 has been gathering dust for months because AMD has completely ignored an entire, major category of Linux distribution. For example, the bug in authatieventsd.sh where it doesn't point to /var/run/xauth - that's been known since at least 8-3, but with both 8-4 and 8-5 I had to manually patch it. If AMD was testing on a Debian(-based) system, this likely never would have been a bug to begin with (I assume).

I'll have to go search for your issues and system configuration (I don't keep files on you all ) but there's no question that BIOS remapping is still causing a lot of hurt with 4GB or more. At first glance it seems that some BIOSes are saying memory is present in places where it really is not. A couple of people have recently reported good luck limiting the amount of memory used by the kernel to 3.5M or so; doesn't sound like an ideal solution but sure seems easier to test than pulling out DIMMs.

My problem with this statement is this - what about the individual customers who also spend their hard earned cash on your products? Certainly none of us spend in one go what the corporations running SLED and Red Hat do, but we are still your customers, despite the fact that we are an extremely difficult bunch to quanitfy*.

Depends what you mean by the question. If you're saying "we should be doing testing on a Debian system now that we're targetting consumer users" then I think we're in violent agreement. If you're saying "no matter what oddball combination of system, distro and patches a customer runs you need to work on their system" that gets tricky because we reach a point of diminishing returns. Top priority is making sure we always run reliably on major out-of-box distros so at least every customer has a starting point and can easily find out what made the difference between working and not-working.

It seems to me that Red Hat, SUSE and Debian are the 3 main distros from which the majority of other distros are based. Only testing on 2 out of 3 just doesn't make any sense to me, regardless of what the majority of corporate customers use. It's like a 2-legged tripod... or something, I'm obviously not very good with analogies.

2-legged tripod is good enough. Nope, we agree.

I have problems with that as well. I absolutely, wholeheartedly, unequivocally support your efforts releasing docs and fostering the open drivers - that's the main reason I bought an ATI card I didn't actually require. However until such a time as either of these drivers has something resembling feature parity (notwithstanding the DRM features [not the Direct Rendering Manager] which are likely to remain fglrx-only), fglrx should be aimed at anyone who has purchased your hardware(any which fglrx supports) with the intention of using it on Linux. Anyone with an R600 card and problems with fglrx is bascially S.O.L. right now. It would seem doubly so if they use a Debian-based distro.

I think we will get R600 3D running on open source drivers before we get an installer smart enough to work with every distro variant and patch combination out there. That said, there are only a finite number of open source developers available to help debug system-specific issues and I'm already seeing a lot of users who don't want to run open source drivers because "they have to build them and that's a big pain".

I'm tempted to offer up the spare M3A motherboard (AMD770/SB600) I have if it might expedite getting a Debian-based test box up and running (and hopefully finding my issue's remedy). I don't have any of the other necessary parts for a system spare though... If your testing systems are somewhere other than Markham though I don't think it'll happen.

We have lots of hardware, but thanks. Hardware is not the problem -- good testers are expensive no matter where they are.

*I had an idea while writing this post, it's something that would require quite a bit of work though I expect. Anyway here it is: Inside the boxes of ATI cards (channel partners would have to participate also) there could be a slip of paper asking "Do you intend to use this video card under a Linux-based operating system? If so please go to www.amd.com/linuxcounter and let us know to help us make our Linux software as excellent as it can be." At the website would be a short form where customers could enter the product they bought and its serial number(so as to prevent abuse), and the distribution they use. This could help AMD generate some hard data on who's using what and in what numbers. The card-in-the-box isn't strictly necessary either, as long as people know about the site and to submit their info. Anyway, just an idea.

That's a good idea. There have been some attempts to collect that kind of information, but it's really hard to get the numbers matched up from different sources so the results aren't all that credible. We have a problem reporting tool for Windows (at least we used to) which collected some info about the ATI product and the OS then formatted up an email which could then feed into bug tracking systems, but I think a lot of folks didn't like even that level of "phoning home". Do you think enough people would bother that we would get a representative number ?

So far the most credible numbers seem to come from third party web sites which track browser and OS type. They don't identify whether the graphics card is ATI or something else, but market share info is available separately and even if we assume we have 100% market share the numbers aren't that high.

I hope my frustration hasn't given the wrong impression. Despite it, I'm still a big supporter of AMD (always have been) and the work you cats are doing to provide an open driver, and the interaction/support you, specifically, provide here, bridgman. From what I've seen at nvnews.net while looking for solutions to the less-major issues I have with my Nvidia card, the Nvidia staff there don't do much but make excuses, and sow misinformation. Apart from taking bug reports that is (they're not all bad I guess). Dealing with the same issue driver after driver and reading about many other people doing the same with other issues is a recipe for aggravation though. Anyhow, I think I've posted more than enough here, thanks for being here to hear what we have to say bridgman, I'd be a lot more frustrated were it not for your insights into what goes on behind the scenes.

Thanks

[bridgman]

The opensourcedriver manages 2D and XVideo fine, but 3D is limited to glxgears or it'll bring down the system.

Dave and Alex pushed some pretty significant fixes for RS4xx recently; have you tried the open source drivers in the last couple of weeks ? You definitely need latest DRM and Mesa, not sure about radeon and X server.

Here's one of the recent fixes : http://airlied.livejournal.com/59351.html

[duby229]

I think we will get R600 3D running on open source drivers before we get an installer smart enough to work with every distro variant and patch combination out there. That said, there are only a finite number of open source developers available to help debug system-specific issues and I'm already seeing a lot of users who don't want to run open source drivers because "they have to build them and that's a big pain".

Hi Bridgeman. I just wanted to add that may be true in the short term, but sooner rather then later (hopefully) the open source driver will get built with the xserver. I'm not sure how RPM based distro's, or how Apt based distro's do it, but with Gentoo it uses an environment variable called VIDEO_CARDS that allows you to set the video drivers you want to install along with the xserver. I'm positive that Ubuntu or Fedora, or SuSe must have some similar mechanism for installing the proper device drivers.

All we have to do now is wait for the open source driver to mature. After that there really wont be any point in fglrx. I can understand it as a stopgap, but as long as MS enforces it's WHQL certification, fglrx will never be a viable option. Until ATi is able to put it's full might behind it, fglrx is effectively worthless in every possible way.

I personally think they should stop all further development right now, and devote every person that is currently working on it into getting documentation and code out the open source community. When it all boils down to nothing in the end that really is the only viable choice they actually have. Devoting resources to fglrx is simply delaying the inevitable. And it's a shame too becouse that delay is only hurting themselves.

[duby229]

That's a good idea. There have been some attempts to collect that kind of information, but it's really hard to get the numbers matched up from different sources so the results aren't all that credible. We have a problem reporting tool for Windows (at least we used to) which collected some info about the ATI product and the OS then formatted up an email which could then feed into bug tracking systems, but I think a lot of folks didn't like even that level of "phoning home". Do you think enough people would bother that we would get a representative number ?

So far the most credible numbers seem to come from third party web sites which track browser and OS type. They don't identify whether the graphics card is ATI or something else, but market share info is available separately and even if we assume we have 100% market share the numbers aren't that high.

Hi bridgeman. Sorry for being a pain. I just wanted to chime in here as well. Thanks for your time and patience...

I can pretty much promise you beyond the shadow of a doubt that any of the market share numbers you get based on web browser and so on is totally incorrect. The problem is that most Linux boxes are servers, and great deal of them (even newer ones from last year) are using rage128 chips. I'd say that makes up the vast majority of the linux market share.

The fact is that a significant linux market exists. But ATi has --not-- leveraged it. This may upset a few people, but I firmly believe that you can easily get away with using a low end radeon on a server board. It may be overkill, but it will have an effect on your bottom line. Especially considering the advances in virtualization technology. AMD will be releasing a new IOMMU that supports virtualizing IO in the near future. That in combination with the proliferation of Linux thin clients in various workstation environments makes a significant market for you to target.

Additionally, even though desktop linux makes up a small minority of linux market share, the number of video cards being used in desktop linux all added up equates to millions of dollars, that are mostly going into nVidia's pockets. It may be small in comparison, but we are still talking about --millions-- of dollars.. If you guys took the time to get the drivers in order, and then --specifically-- marketed towards the linux community I could absolutely guarantee your revenues would increase by a worthwhile margin.

[bridgman]

Hi Bridgeman. I just wanted to add that may be true in the short term, but sooner rather then later (hopefully) the open source driver will get built with the xserver. I'm not sure how RPM based distro's, or how Apt based distro's do it, but with Gentoo it uses an environment variable called VIDEO_CARDS that allows you to set the video drivers you want to install along with the xserver. I'm positive that Ubuntu or Fedora, or SuSe must have some similar mechanism for installing the proper device drivers.

This is a tough one. Most users (and most distros) try to avoid updating the server if possible, because so many other bits need to match. There's a lot to be said for picking up an entire xorg release, which AFAIK includes all the drivers as well.

That said, I don't actually remember seeing any update mechanism that allows you to pull down an entire xorg release set. Nuts, something else to go learn

All we have to do now is wait for the open source driver to mature. After that there really wont be any point in fglrx. I can understand it as a stopgap, but as long as MS enforces it's WHQL certification, fglrx will never be a viable option. Until ATi is able to put it's full might behind it, fglrx is effectively worthless in every possible way.

Not sure I understand this. WHQL is a driver quality and conformance test. No test is perfect but in almost every case passing WHQL makes the driver better not worse. WHQL doesn't care much about OpenGL, of course, and we don't run WHQL on the Linux driver builds; I don't think the common code is adversely affected by having to pass WHQL on the Windows drivers though... am I not getting your point ?

I personally think they should stop all further development right now, and devote every person that is currently working on it into getting documentation and code out the open source community. When it all boils down to nothing in the end that really is the only viable choice they actually have. Devoting resources to fglrx is simply delaying the inevitable. And it's a shame too becouse that delay is only hurting themselves.

Remember what the fglrx driver was initially written for -- workstation systems, generally OEM preloads with pre-installed drivers, where the requirement is maximum performance, ISV certification and specific (sometimes uncommon) OpenGL features. We do see open source drivers being used very widely, but there are three areas where the open source drivers are not going to be able to compete :

- workstation graphics (this is a highly competitive market; nobody is going to dump their proprietary software into an open source driver)

- gaming (same thing; proprietary software is a big part of the competitive advantage)

- legal playback of BluRay etc; again, not possible with an open source driver stack

For most other scenarios, I expect users will get an open source driver out-of-the-box and never bother to upgrade.