AMD Catalyst 8.5 For Linux

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

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

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.

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

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

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

[duby229]

I'm guessing you want something like what Intel is doing? Dump money and support and keep everyone happy. Granted it works, and the Linux Intel driver is probably the best out there. However, it would be no surprise to me that once Larabee hits the streets, Intel would pursue its own Linux program and not be as supportive anymore.

Not even really to that extent. I dont like Intels monopolistic practices, but you have to admit they have a much better driver then any of the drivers for ATi. Obviously it works. ATi doesnt even have to go so far as Intel did. Although it would be nice for them to really get involved with open source projects like gem, or gallium, or kernel modesetting. It would be cool if ATi officially supported and funded projects like these exclusively.

The way I consider it is that right now it is Intel that is shaping the future of the linux graphics market. nVidia doesnt have a CPU. Unless nVidia comes up with a decent x86 cpu in the next 5 years they will be left in the dust. It's almost certain that nVidia is going to die. And It is Intel that is laying the ground work for the future of graphics in linux. Not ATi.

We all know ATi has the better hardware, and I personally dont think Larrabbe has anything interesting to offer. A bunch of broken down simplified x86 cores aint gonna cut it. The ISA just doesnt scale well to multicore. Especially not something so massivelly parallel. I dont think Intel has now or will have in the near future a graphics architecture capable of competing on performance or functionality. However it is beyond a doubt that Intel will take the linux market given current trends.

[Melcar]

I'm guessing you want something like what Intel is doing? Dump money and support and keep everyone happy. Granted it works, and the Linux Intel driver is probably the best out there. However, it would be no surprise to me that once Larabee hits the streets, Intel would pursue its own Linux program and not be as supportive anymore.

[duby229]

Sorry Bridgeman. Not trying to be a pain or anything, I promise.

I guess, we'll have to agree to disagree. It's a shame though, becouse I'm 100% convinced that if you dropped all support for DRM today, and stopped all further development on fglrz and devoted those resources into open source you'd be able to capture the entire linux market. It wouldnt have any effect at all on your windows market. Just keep on doing what you do there...

I may not know the linux graphics subsystem very well, but I'm not entirely retarded. I do have at the very minimum at least a fundamental understanding of micro architecture and fabrication. At the very minimum I understand the fundamental idea's behind modern driver development. I'm no expert by far, but I'm not entirely naive either. I can understand why you publicly deny reverse compiling nvidia's drivers, and looking at the architecture, but come on now.... I've seen an application that could take a binary and convert it directly into C. Granted it didnt have have any comments, and reading through it was very cryptic, but you could still follow the code.

And I do understand that most of fglrx is common code. But windows drivers dont just run magically on linux. Take those precious resources and devote them to open source. You'll wind up with a much better product in the end.

And again as far as HDCP goes, I really dont want to get into it, but suffice to say that I dont have ready access to the decryption key. I can think of at least half a dozen laws that apply. And becouse of this every possible effort should be made to disable the DRM in hardware, and to circumvent the DRM in software. Those efforts are already underway. Fortunately the open source ATi drivers with Radeon and radeonhd wont support the drm in hardware. The only thing left is circumventing the software. And like I said those efforts are already underway. Sooner rather then later all of us will be able to watch and copy DRM'd content entirely with open source drivers and software. And we'll be able to do 100% transparently.

[bridgman]

I disagree. I acnt see one instance where a closed driver would provide some kind of benefit. If you can name one instance where a closed driver might be of some benefit then you might persuade me, but I cant think of a single one.

I have already offered a couple -- protecting competitive advantage in our workstation and gaming products, and fulfilling legal requirements to protect high-def video content. If you keep saying "those don't count" then I admit I will eventually run out of reasons

The only thing I can think of is that your thinking that using a closed source driver is somehow going to "hide" something. Come now, I'm not that naive. I may be a noob, but I know full and well that the first thing nVidia does when ATi releases a new driver is reverse compile it, and you do the exact same thing with theres. When ATi releases a new chip the first thing nVidia does is put it under an electron microscope, figuratively and literally, and you guys do the same.

Actually, I don't think either of us do that. I do remember the days when memory chips and microprocessors were run through a SEM and blown up to cover the floor of a large room (I may still have some rolled up transparencies down in the basement) but it's not worth the effort. The point is not "stealing ideas", it's that when you put something out in open source your ability to legally protect the IP is impaired.

I don't think either of us would live long enough to pick through a disassembled copy of a modern driver. The drivers were over 2M lines of code when I joined ATI and maybe ten times that today. It's just not worth the effort to pick through a code base that size. Heck, it would be more efficient to randomly dial extensions at your competitor and ask each person who answered to explain how the technology worked. I'm sure someone would tell you

And that is entirely ATi's fault. 100% they arent actually expected to work for free are they? They have to have a day job. These guys have families to feed just like everybody else. Pay them enough to make it there day job, and put the guys from fglrx working on it full time too. It's not magic. It requires some talent yes, but it also requires some funding and incentive. Bottom line it's ATi hardware and if they want to tap into this market then they need to devote the resources required to make it worthwhile.

But if we hire enough developers to write a competitive high performance driver, which would mean that we would end up with about 90% of the open source graphics community on our payroll, how is making it open source going to improve anything ? Almost all the people who could make it better would already be working for us

You do understand that most of the developers who contribute to fglrx are working on common code and are not dedicated to Linux, right ? Are you asking us to shut down Windows development in order to make a better open source driver, or just have the Linux-specific people work on open source.

I'm not much in the mood for debating DRM at the moment, but suffice to say that HDCP itself breaks at least half a dozen laws in the US alone, and by supporting it in your drivers ATi is too. It's simply not worth your time. It will be hacked. I would love someone to try and sue me for using a HDCP hack. I'm a poor person, but I'sd take it to court and run with it becouse I know for a fact beyond that shadow of a doubt that I would win by a significant margin.

OK, you're losing me here. HDCP is an Intel hardware standard for encrypting the video that goes out to a display. What laws does it break ?

Bottom line is HDCP really isnt your concern. It is currently being worked on by --far-- more capable open source projects. Your efforts arent wanted or needed.

Again, I feel like I'm missing something here. HDCP is implemented in hardware; the software just turns it on and off and handles error conditions. What are the open source projects doing ?