AMD Catalyst for Linux 9.12 has been released. The most important changes are rather nice and much needed additions to the CCC (control center). There's also OpenGL 3.2 support. Renaming the current ebuild worked fine. I did *not* test with kernel 2.6.32. Only with 2.6.31. There is no support for X.Org 7.5 yet (xorg-server 1.7).
(In reply to comment #0) > Renaming the current ebuild worked fine. I did *not* test with kernel 2.6.32. > Only with 2.6.31. It dosn't compile with 2.6.32 but the patch for 9.11 works for 9.12 too. PS: The patch still tests for the kernelversion in the ebuild, not in the sources.
AMD released a "hotfix" update of 9.12: http://support.amd.com/us/kbarticles/Pages/ATICatalyst912Hotfix.aspx In this version OpenCL and XvBA actually work. However, this would need to be packaged separately as it comes inside a zip file and downloading it is not possible unless you click the download link on that page. There's also a mention of "X.Org 7.5" in the "check.sh" script in the zip, suggesting that X.Org 7.5 *might* work. I didn't test. Any volunteers?
(In reply to comment #2) > There's also a mention of "X.Org 7.5" in the "check.sh" script in the zip, > suggesting that X.Org 7.5 *might* work. I didn't test. Any volunteers? > No, doesn't work: (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so dlopen: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: UpdateSpriteForScreen (EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so (II) UnloadModule: "fglrx" (EE) Failed to load module "fglrx" (loader failed, 7) (EE) No drivers available.
I finally managed to get fglrx working under the 2.6.33-rc kernels (not tested with 2.6.32) but the "downside" is that you have to downgrade Xorg from 7.5 to 7.4(*). 1. Copy the ebuild ati-drivers-9.11.ebuild -> ati-drivers-9.12.ebuild 2. Copy 2.6.32-9.11-fix_compilation.patch to 2.6.32-9.12-fix_compilation.patch (see files/kernel sub directory) this ones fixes the compiler's complaints about not found synbols / void pointers. 3. Add the the following symlinks (NOT an elegant way to fix the compilation issues, I apologize): cd /usr/src/linux/include/linux ln -s ../generated/autoconf.h . ln -s ../generated/utsrelease.h . 4. emerge ati-drivers 9.12 (also do not forget to do a depmod -a) 5. adapt your xorg.conf to use fglrx 6. eselect opengl set ati 7. If you were using the radeon kernel module, I strongly suggest you to *reboot* your machine instead of just rmmod-ing radeon and its friends. (*) See bug #290739 , french-speakers can also read the article there : http://www.gentoo-quebec.org/wiki/index.php/R%C3%A9trograduation_de_Xorg_7.5_vers_7.4
with regards to the kernel headers issue, the upstream is aware of it (see comment #3 of bug #298258).
no one willing to bump it?
(In reply to comment #6) > no one willing to bump it? 10.1 will appear in two days or so, so now it doesn't even make sense anymore to bump 9.12.
10.1 will be released next week. cf. http://twitter.com/CatalystMaker It makes sense to get 9.12 in tree, maybe 10.1 might have regressions?
10.1 is out: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-1-x86.x86_64.run I didn't test, and probably never will. I had enough with ATI/AMD.
(In reply to comment #9) > 10.1 is out: > > I didn't test, and probably never will. I had enough with ATI/AMD. You did good. I tried 10.1, it's still not abi-compatible with x11-base/xorg-server-1.7.4. Same bloody "undefined symbol: UpdateSpriteForScreen". Suck big time. regards, Sebastian
Created attachment 217668 [details, diff] Patch to correct ebuild for 10.x version numbers This patch changes the tests in the ebuild from the string comparision ">" to numerical comparison "-gt". (At second thought one may also remove the test altogether ...)
A hint from a Suse forum I came across: When you switch from 9.11 to 9.12 or 10.1 and as a result you don't get any output to the monitor it may help to delete /etc/ati/amdpcsdb. It helped me. http://forums.opensuse.org/hardware/429007-ati-catalyst-9-12-x-blank-screen.html
*** Bug 303523 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > it may help to delete /etc/ati/amdpcsdb. This is true in general. For any XRandR, or display-state, etc. I just deleted the whole /etc/ati/ folder, and reinstalled ati-drivers, to get back a clean state. Helped me every time something weird happened (like XRandR not detecting the screen’s resolutions anymore), back when it was still incompatible to composite/xinerama and 2.6.29 kernels.
By the way: Does anyone know why this is not in portage yet? We ATi users don’t have much of a choice, and already have masked xorg-server-1.7* and friends anyway. So we would appreciate to at least be able to use a less-buggy driver. Since 9.11 has a very annoying problem, where when you roll up Yakuake (quake-style terminal) while something big is compiling inside (like a bigger ebuild or the kernel), the system hard-crashes to the level where neither num lock nor pinging work anymore.
Why is it taking over a month to get ATI's monthly driver release into portage? ATI's drivers are a trainwreck of Godwin-esque proportions and each new release is a glimmer of home for those of us who are damned. ps. big thanks to the users who contributed 10.1.
I would certainly appreciate the portage version bump.
(In reply to comment #16) > Why is it taking over a month to get ATI's monthly driver release into portage? > ATI's drivers are a trainwreck of Godwin-esque proportions and each new > release is a glimmer of home for those of us who are damned. You've basically answered your own question. "Working" on ati's binary driver is a pain and would take up a lot of the very little time its maintainers have these days. Please bear with us. Thanks
FYI 10.2 /should/ deal with Xorg 1.7.x series. I am trying to deal with your patch but what was functional with fglrx 9.1x does not work any longer with 10.x :-/ The patch in itself is not guilty (ATI changed some files and some of the existing patches now breaks... what a nightmare... *sight*). I hope to see a functional Radeon KMS soon to kick out that fglrx forever.
(In reply to comment #19) > FYI 10.2 /should/ deal with Xorg 1.7.x series. Yeah! I hope so. It should also deal with these friggin kde4 glitches of unresponsiveness and sloooooooooooooooooooooooowwwwwwness. [snip] > I hope to see a functional Radeon KMS soon to kick out that fglrx forever. Huh? KMS work for me with .32 and .33. BUT THE MAJOR DRAWBACK: powermanagement. My HD3650/Thinkpad is getting unbearable hot. From 40 deg. celsius to 75° celsius. WTF? IMHO it is not important to pray the pure ideology of OSS, I want my blood notebook to work as good as possible.
Well, Radeon KMS is supposed to work with a single card, but those of us who have 2 48xx Crossfired cards are likely to experience a blank screen when the radeon module is loaded in the kernel with modeset=1. See bug#297019 for additional details.
Please don't remove ati-drivers from the tree. The open source driver are not nearly usable for professional work with 3D. The OS driver have poor performance in OpenGL compared to fglrx and lack features like OpenGL Shading Language. The second issue is the high power consumption of the OS driver. I will post my ati-drivers-10.1.ebuild, which i use with kernel 2.6.32 since its release.
Created attachment 219391 [details] ati-drivers-10.1.ebuild
This ebuild is more or less the version from this bug, but if i remember correctly i think i had to delete some patch lines, because they did not work.
if I recall correctly I had to remove the last entry in 2.6.32-9.11-fix_compilation.patch - namely: --- work/common/lib/modules/fglrx/build_mod/kcl_io.c +++ work.new/common/lib/modules/fglrx/build_mod/kcl_io.c @@ -37,8 +37,9 @@ */ #include <linux/version.h> #include <linux/autoconf.h> #include <linux/poll.h> +#include <linux/signal.h> #include <asm/io.h> #include "kcl_config.h"
Created attachment 219393 [details, diff] 2.6.32-9.11-fix_compilation.patch just in case anyone needs it in its original version
Mat, are you sure it is necessary? the 10.1 built fine w/out patches here
(In reply to comment #27) > Mat, are you sure it is necessary? the 10.1 built fine w/out patches here > if it builds, can you add it to the tree? maybe mask it. It would be great to use the newest drivers in time without dealing with overlays and patches myself. if the drivers makes things worse, one can always switch back.
(In reply to comment #27) > Mat, are you sure it is necessary? the 10.1 built fine w/out patches here > Hi Luca, sorry for the confusion: the patch is only needed for it to build with 2.6.33-rc* kernels - I haven't tested it myself but read that it's supposed to compile and run fine with 2.6.32
I can confirm, that 10.1 is compiling and working fine with 2.6.32-gentoo-r5.
right now there is an ebuild in portage that doesn't use the patch. Please tell me if you need the patch in and I'll put it. Sorry for the lateness.
(In reply to comment #31) Thank you Luca. :) It may get a bit heated in here, but we appreciate it.
I've finally managed to get a working 10.1 (tested against 2.6.32-gentoo-r5 and 2.6.33-rc8 using gcc 4.4.3) in way that leaves the original ebuild untouched : 1. Create a local overlay (as needed) that will host x11-drivers/ati-drivers 2. Copy /usr/portage/x11-drivers/ati-drivers/ati-drivers-9.11.ebuild to your local overlay and name it ati-drivers-10.1.ebuild (No need to change the file) 3. Do the same with /usr/portage/x11-drivers/ati-drivers/files 4. Download 2.6.32-10.1-fix_compilation.patch and put in your local overlay (under files/kernel), This file is basically the same than 2.6.32-9.11-fix_compilation.patch but leaves kcl_io.c unpatched. 5. Digest the ebuild (ebuild ati-drivers-10.1.ebuild digest) Et voila! Waiting for the 10.2 :-)
Created attachment 219665 [details] Patch for the 10.1 release Same as the original (2.6.32-9.11-fix_compilation.patch) but leaves kcl_io.c untouched.
Very nice! @lu_zero: Maybe you can put this right in portage? :)
(In reply to comment #33) Ok, one question: You say that it compiled. But does it actually work? And does it work as it should? Or is it just sparks and errors inside, that we won’t see, but will bite us later?
It compiles and installs fines (the machine is running under this revision and no troubles for now.
I'm trying to be extra careful with patches since I have to rely to external feedbacks to apply them since I cannot test it myself any more (till I manage to buy a newer gpu =|), so if I have enough people telling that works I'd apply it given it isn't too problematic (this one looks quite straightforward)
(In reply to comment #37) I strongly recommend using the ati-drivers-9.11-to-10.1.ebuild.patch alone on the 9.11 ebuild. Because using “> 8” for numeric comparison is really a bug. (And not the 10.1 ebuild attached here. So your patch will still work.) Also, strangely, the download of the driver did not work the first time (without the patch), since for some reason, it tried “distfiles/fglrx-installer_10.1.orig.tar.gz” (and “https://launchpad.net/ubuntu/karmic/+source/fglrx-installer/2:10.1-0ubuntu1/+files/fglrx-installer_10.1.orig.tar.gz”) instead of “distfiles/ati-driver-installer-10-1-x86.x86_64.run” I now was able to install it here. Only a few warnings and a list of files below “QA Notice: Files built without respecting LDFLAGS have been detected”. I will try it out now.
As far as I can see, the 9.11 ebuild (found in the portage tree) incorporates your patch (compares with "-gt" instead of ">" ).
@lu_zero: OK, I run the driver for a couple of hours now, did a couple of tests, and it runs fine. (In reply to comment #40) Here definitely not. But doesn’t matter. As long as whatever is in portage later, is patched. :)
Does this 10.1 ebuild build with xorg-server-1.7.x?
(In reply to comment #42) > Does this 10.1 ebuild build with xorg-server-1.7.x? The ebuild works with 1.7. The driver doesn't.
10.2 is out. Still a no go with xorg-server-1.7*. Crap.
Let's hope for the 10.3...
Worth mentioning that (after testing): + 28 Feb 2010; Fabio Erculiani <lxnay@gentoo.org> + +files/ati-drivers-2.6.33.patch, ati-drivers-10.1.ebuild, + ati-drivers-10.2.ebuild, + +files/ati-drivers-fix_compilation-bug-297322.patch: + add 2.6.33 kernel support and really close bug 297322 +
To use with 2.6.35, one needs to add #include <linux/slab.h> to kcl_wait.c otherwise compilation fails with: kcl_wait.c:55: error: implicit declaration of function ‘kmalloc’
