AMD Catalyst 8.5 For Linux

[Redeeman]

#164:
"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 ?"
I have not tried anything older.. will anything older work with .25?

"Is this under Wine/Cedega/whatever or native ? Any other info we could use to understand what is happening ?" well.. actually, wine is the one thing that DOESENT do this.. unfortunately wine is useless, so it probably quits before it has a chance to hit the reason.. glxinfo segfaults at one point. when i start amdccl, it works fine, but when i quit it, it segfaults. same with neverball.

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

"Yeah, until you get DRI=yes it's not worth going any further."
neverball runs fluid in 1280x1024, i do not believe a core 2 duo 3ghz is capable of software rendering that game, in this resolution..

"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. "
I am reasonably skilled with these sorts of things (having dealt with fglrx before on my laptop, and nvidia on several computers), and i can tell you this, the correct libGL is in place, xorg loads fglrx correct, and it does not complain about dri (which it did untill i modprobed fglrx), and fglrx kernel module loads correctly..

i will attempt to debug this further..

[chikazuku]

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

I'm running X Server 1.4.0.90 (with the radeon-driver as it came with it [edit]Appears to be xf86-video-ati-6.8.0-r1[/edit]) and Mesa 7.0.2. Not sure about DRM, isn't that a kernelmodule? I'm running kernel 2.6.25, the X.Org log says:

(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.28.0

I will try an SVN-version of X.Org if needed.

[bridgman]

neverball runs fluid in 1280x1024, i do not believe a core 2 duo 3ghz is capable of software rendering that game, in this resolution

I'm not 100% sure, but I think in the absence of DRI you fall back to indirect rendering, which used to mean "software rendering" but these days is just as likely to mean AIGLX, ie full hardware acceleration with some protocol overhead, which on a fast CPU is only a bit slower than DRI.

If you are getting good performance on neverball and Wine is complaining about DRI this sounds like the case.

Not sure if I asked which version of Wine you are running; there seem to be some pretty serious regressions recently and I see recommendations to go back to considerably older versions when troubleshooting.

[Redeeman]

i have found the problem... for SOME reason /usr/lib/libGL.so.1.2 was corrupted.

I now have direct rendering.

It still brings up wrong resolution though. The funny thing is, it does detect edid properly in xorg.log, but then it somehow just sets 1680x1050 as resolution.. and lists up to and including 1920x1200 in amdccle.

now applications does not crash when exiting.

HOWEVER.

it is quite buggy still.. i found that wine is somehow able to leave the opengl driver in a broken state (atleast for itself)

if i start world of warcraft with -opengl, it might or might not start (giving bad glx drawable), if i then start neverball and close neverball, i am able to start world of warcraft in wine, ONCE, if i start it again, it gives the bad glx drawable - neverball is able to fix it..

performance isnt terribly good, alot worse on this c2d 3ghz box than my amd64 2ghz with 6600gt agp. I didnt expect HD 3450 to be fast, but can you tell me if im hitting around the correct performance? (im getting ~8-10fps in wow @ 1024x768 almost full details).

im still having the "reaction" issue with 2d. if i press a window to move it, it takes like.. 0.2-0.5sec before it starts moving, and then its perfectly fluid (and no, i do not use compiz/composite/aiglx).

Ill give you this though, 2d performance beats the crap out of nvidia on 8xxx.

[oblivious_maximus]

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.

Basically I can't log out (or start a second, additional Xserver on my TV) without an unrecoverable lockup. I have tried with only 2GB installed (not with 8-5 though), but nothing changed. Also, my mtrr does not account for all my RAM, which could also be part of the issue(and could also ultimately be Asus' issue - I wish I'd bought a different board when I sent back my first M3A after frying the BIOS), but I can't figure out how to fix it.

To limit the kernel to 3.5 gigs, would I just use mem=3584M as a kernel boot option? I remember I've tried to do that to specify the full 4GB but it wouldn't boot with that option (mem=4096M iirc), complaining about insufficient RAM, again iirc.

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

Well that sounds good (3D on open source in the not-too-distant future)! I for one will not be complaining about having to rebuild the driver, once I start using it that is. I'll need TVout support too before I do though. Of course this assumes there's a good doc somewhere that's easy to find that details building the driver (I'm sure there is).

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.

The first one. I definitely don't think you should spend much (if any) time worry about whether fglrx works on GoboLinux or similar niche distros, but if you're targetting regular consumers (ooh I hate that word in that context), then yeah, definitely you should be testing on at least one Debian-based distro (obviously my preference being Debian itself as it amounts to the lowest common denominator). Without that, you're definitely missing a leg on your tripod. :P

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

I had a feeling AMD didn't need its customers to provide AMD-based hardware for testing. :P

Do you think enough people would bother that we would get a representative number?

Assuming you weren't asking for much more details than the product and serial number, distro, and maybe an email address, I think you might, but ultimately I can only speak for myself. I'd be a bit torn if you were asking for more info than that, but if I thought it might help AMD improve support, I'd probably do it. There is a point where asking for too much info would turn me off though (address & phone number for example).


I'm just going to try and touch on some of the things posted about since I last posted:

As to the question of FLOSS devs not having the time for performance optimization - I think AMD should eventually have some of their people make some efforts to optimize the open drivers. Until such a time as 3D is up and running reliably though, this can certainly (must certainly) wait. I'm not talking about engaging in a video card performance arms race with Nvidia, or optimizing to the max for every new game that comes out (hehe I guess that's not much of a concern right now on Linux), just using the experience of a decade of 3D driver work to implement performance optimizations where they'd be of use, not making them(the open drivers) quite balls-to-the-wall, screaming fast, but at least improving them performance-wise beyond the level that the FLOSS devs are prepared/able to themselves.

Once the open drivers are up to snuff, I think AMD would also do well to create a closed DRM-features driver that can augment the radeon and radeonHD drivers for those who want to playback Bluray discs but not use fglrx. I personally would have no interest in it myself, until such a time as I can strip a Bluray disc of AACS I won't touch that garbage, but as you say bridgman, if(when) Linux ever sees significant market share increases, some people will want those features. It would be great if one could just grab a DRM package and tack it on. I don't know about the viability of that, I believe it's been discussed a bit in other threads. It would certainly be a better option I think for the people who would prefer to use the open driver(s), than running the open driver except when you want to play a movie (and jumping back to my last paragraph, that would be a similar situation - I certainly have little interest in running the open driver for everything but games and then having to run fglrx to play a game with decent performance).

I also think AMD should make it possible to use hardware acceleration to decode unprotected content with the open drivers. Maybe this already in the cards? Should be a given IMHO. I guess with Stream SDK out now, we just have to wait for the MPlayer and VLC (and GStreamer and Xine) devs to implement GPU decoding?

I mentioned this a few days ago (I think earlier in this thread actually), and I realize it'll probably never happen, but I would personally love to see a line of cards that DO NOT support playback of protected content of any kind. I look at the HDCP sticker on my 3650 and it grates upon my soul. I can't help thinking I'd have a lot less issues (as would fglrx) were it not for that damn protected content BS.

bridgman you are truly to be commended. I can't motivate myself to keep writing this post even though I'm sure there are some more points I had some kind of a reply to when I read the posts after mine the first time. You just keep answering all these epic posts! Kudos eh!

edit: maybe I haven't looked in the correct spot, but one thing Nvidia has going at nvnews.net is a well defined guide to creating the appropriate logs and info for filing a bug report. They're kinda jerks about not responding to any inquiries without that info, but I presume when they get that info it helps them fixing the bugs they care to fix (the ones the staff there aren't sowing misinformation about). Are there some similar guidelines for ATI? A bug report info extraction tool would be handy...

[Redeeman]

as for which drivers should have focus, IMO AMD should simply EOL fglrx, and work exclusively on free drivers..
if workstation graphics people wont let their applications being run on a driver simply because its opensource.. well, then they are stupid, and i dont give a damn what they think. As for DRM and such crap, that should be possible to handle in an addon to the free driver.

This way all optimizations and stuff would go into the open driver, and not some secret amd blob which people realistically have no way of properly using.

As for distribution support, OFCOURSE the drivers(fglrx right now) should work there, i agree, amd shouldnt be spending time on writing weird scripts to make it work there, but the driver should really just f****** work on _ANY_ distribution which doesent break it by itself.. what im saying is, it should work on VANILLA builds from the various projects, aka, the kernel, xorg and such. If distributions are altering things, locations, or need special packaging scripts, this is no problem, because the distribution will simply take care of that themselves.

[NaterGator]

I've never understood why the opensource drivers couldn't be written to accept the equivalent of a closed-source DRM module.

For the most part the entire rest of the linux architecture is open source and it's not really like DRM is going to ever be able to prevent unlicensed use (look at the FairUse4WM on closed source windows as a prime example). That doesn't mean AMD/ATI can't appease content owners though and at least provide them a 'secure' closed-source branch of the open source driver.

[Extreme Coder]

I don't think we test on Debian today -- mostly RHEL, OpenSuSE (SLED upstream) and we're starting to get some coverage on Ubuntu, which should help a bit with Debian.

So no Mandriva?
Let me test Mandriva for ya :P

[bridgman]

I've never understood why the opensource drivers couldn't be written to accept the equivalent of a closed-source DRM module.

The issue is that everything *below* the DRM stuff needs to be closed source and difficult to hack (you need to protect the decrypted stuff) so you end up with most of the stack being closed source. Even seemingly good targets for open source like display don't really work out because robust output protection is an important part of the DRM solution.

There's no question that "just a few bits" are affected by DRM, but "all the stuff in between" needs to be secure as well and you very quickly end up with a 95% closed source driver. I'm guessing at the 95%, but it's closer to 95 than 50.

Just so it's clear, we don't enable any DRM stuff in our Linux Catalyst drivers today.

So no Mandriva? Let me test Mandriva for ya

I think we have some Mandriva users in the beta test program; will check.

[Extreme Coder]

The issue is that everything *below* the DRM stuff needs to be closed source and difficult to hack (you need to protect the decrypted stuff) so you end up with most of the stack being closed source.

Even seemingly good targets for open source like display don't really work out because robust output protection is an important part of the DRM solution.

Just so it's clear, we don't enable any DRM stuff in our Linux Catalyst drivers today.



I think we have some Mandriva users in the beta test program; will check.

Ok, in any case, I'm available for testing at any time