View Full Version : AMD Releases Catalyst 9.6 For Linux
cutterjohn
07-02-2009, 12:52 PM
Sorry, but I'm not having any luck parsing this. Can you help me understand what you mean here ?Short version: cannot install ATI catalyst without modifying the distributed driver package by adding the MSI vendor ID and part # plus optionally what appear to be some setting strings. Alternatively it is also possible to directly install the driver portion only(sans CCC) apparently, but I got derailed on that by a dead link last time I though of trying that out. The second method also involves jumping through hoops as well, and I'm not at all certain if the driver will still look for a card mfg ID or not.
This is just really way offtopic though as it was a nitpick for the windows driver side as well, and I don't really think that we can directly compare the windows catalyst drivers to linux as it sounds like the linux ones are more closely related to the firegl "pro" drivers while the windows drivers are specifically for the radeon retail massmarket line with a separate driver for the "pro" firegl line.
Sarvatt
07-03-2009, 12:59 AM
Thank you for the patch - most elegant I have found on the net.
Kano, I can confirm it works with 2.6.30 unmodified kernel - at least on my openSUSE_11.1 system.
For 2.6.30-git18 and catalyst 9-6 I found that the following one patch to the linux kernel:
add "EXPORT_SYMBOL(find_task_by_vpid);" in pid.c
also makes your patch work with 2.6.30-git18, so fglrx will probably work with 2.6.31 as well.
Looking forward to your patch for 2.6.31 without modified kernel sources!
Here is where find_task_by_vpid stopped being exported incase it helps anyone find a workaround. This is sorely needed for 2.6.31 support.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=17f98dcf6010a1cfd25d179fd0ce77d 3dc2685c3
Try this (for dkms):
diff -Nru fglrx-8.620.orig/firegl_public.c fglrx-8.620/firegl_public.c
--- fglrx-8.620.orig/firegl_public.c 2009-07-07 23:35:39.000000000 +0200
+++ fglrx-8.620/firegl_public.c 2009-07-08 00:54:08.155793160 +0200
@@ -165,6 +165,7 @@
#include <linux/string.h>
#include <linux/gfp.h>
#include <linux/swap.h>
+#include <linux/pid.h>
#include "firegl_public.h"
#include "kcl_osconfig.h"
@@ -1292,7 +1293,7 @@
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
p = find_task_by_pid( pid );
#else
- p = find_task_by_vpid( pid );
+ p = pid_task( pid, PIDTYPE_PID );
#endif
if (p)
{
A user with a Radeon 4890 is complaining of an "unsupported hardware" watermark with these drivers on Ubuntu 9.04. Is that normal or did the user foobar the install?
mtippett
07-09-2009, 10:22 AM
A user with a Radeon 4890 is complaining of an "unsupported hardware" watermark with these drivers on Ubuntu 9.04. Is that normal or did the user foobar the install?
That can occur if the user is using a driver that had the hardware changes "in development", but not released and supported.
It means that it _might_ work, but the user should update to a driver that came out after the hardware was purchased.
(Note that there may be lots of variants of a piece of hardware, the variants may be supported after the original release, so don't always go by the original 4890 release date).
Regards,
Matthew
Thanks, Matthew. I understand what it means, but I was wondering if it was normal with Catalyst 9.6 and a 4890. I guess if it is, the user will have to wait for the next Catalyst.
Originally posted in the open source section;
Whenever I run a 3d intensive application, it'll render properly for a few seconds, then my screen goes black, my monitor loses signal, and my computer completely freezes. It takes no input from keyboard/mouse, audio starts stuttering and sounds like a buzzsaw, and I'm forced to shutdown with the power button.
Whenever I'm playing a game that uses hardware acceleration but is not very intensive (such as StepMania), the game runs fine for 3-5 minutes and then the same problem I stated previously occurs. Screen goes black, unresponsive, etc.
Whenever I'm just running a simple KDE desktop without any desktop effects, I experience no problems. It's only when I'm running an OpenGL application does the problem happen.
Same problem occurs here with new 9.6 catalyst driver.
uname -a
Linux 2.6.29-sabayon #1 SMP Thu Jun 11 13:33:04 UTC 2009 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux
lspci on http://www.sabayonlinux.org/pastie/1249
xorg.log on http://www.sabayonlinux.org/pastie/1247
xorg.conf on http://www.sabayonlinux.org/pastie/1248
When playing a matroska-containered high definition video of the film "microcosmos" (haven't tried any others yet) exactly the same symptoms occur; system freezes.
Occasionally i can ssh to the box, but at other times even that is not possible anymore.
Hope this is of use to the developers.
I will be happy to give more information or test things.
cutterjohn
07-12-2009, 11:40 AM
The black rectangle corruption has now also been observed in other applications, e.g. Gnome Terminal and random appearance of black rectangles in empty desktop shells.
Video playback still consistently locks at least X on awake from sleep. (Black rectangle corruption related? I honestly haven't paid attention enough to remember if it also only occurs AFTER wake from sleep.)
Seems like some things may not be properly restored for the GPU after wake from sleep, given that video is OK BEFORE sleep, but after it consistently freezes at least X. Also the freeze is still there IF compiz/beryl is enabled and then the machine is put to sleep.
I'd suggest possibly that monthly releases be dropped in favor of more tangible goals, e.g. some serious bug squashing.
bridgman
07-12-2009, 11:46 AM
The monthly releases more or less come for free along with the other OSes since the drivers make heavy use of common code. Keeping the code regression-free is the expensive part, and that needs to be done whether we release or not. Dropping monthly releases would not really allow the allocation of more resources to bug fixing etc...
JeanPaul145
07-12-2009, 12:08 PM
The black rectangle corruption has now also been observed in other applications, e.g. Gnome Terminal and random appearance of black rectangles in empty desktop shells.
Video playback still consistently locks at least X on awake from sleep. (Black rectangle corruption related? I honestly haven't paid attention enough to remember if it also only occurs AFTER wake from sleep.)
Seems like some things may not be properly restored for the GPU after wake from sleep, given that video is OK BEFORE sleep, but after it consistently freezes at least X. Also the freeze is still there IF compiz/beryl is enabled and then the machine is put to sleep.
I'd suggest possibly that monthly releases be dropped in favor of more tangible goals, e.g. some serious bug squashing.
I can confirm the corruption, I also have it on my Ubuntu/Kubuntu hybrid machine (currently running/bugtesting kde 4.3RC2 but still using some gtk apps like FF3, OO.o and transmission). While it is quite annoying (and it would be nice if this got fixed), in honesty, there are more serious bugs I'm worried about, like the slow unminimizing bug, which, for now, I've worked around by updating my xorg to a PPA version for instance.
cutterjohn
07-14-2009, 08:29 AM
The X lockups are my priority concern, as they should simply not be occuring, and I've found no work around for those.
The screen corruption is workaroundable by forcing a screen refresh. This doesn't seem to be heat related as aticonfig --odgt was reporting 52.0C which roughly agrees with reports by ATITool under windows w/similar room temps @ idle.
PPAs: I've resorted to that for wine to get GW running, maybe I should try that PPA xorg. Which one is it BTW? The ppa wine 1.1.25 while it allows running of GW, the char selection screen is a garbled mess, while the winehq 1.1.25 release the char select screen is fine, but GW crashes at loading an area. Apparently a regression in ntdll under wine. It's also what causes the downloads to fail CRC checks apparently.
There's also this winebug report, labelled as yet another catalyst bug:
http://bugs.winehq.org/show_bug.cgi?id=18794
9.6 seems to have partially fixed this bug, but not completely.
I suppose that the video freeze problem could be that fglrx is leaving X.org in an incosistent state when waking from sleep as I presume that like nVidia, ATI replaces a chunk of the xserver or renderer. I could be entirely wrong and my original idea of the GPU itself being in an inconsistent state could also be the case, but something is definitely being overlooked there somewhere in the suspend/resume code. (Might even be a kernel/X.org bug for all I know that nVidia/Intel work around.)
kubunteando
07-23-2009, 12:52 PM
I follow you quite often and I would like to let you know that Catalyst 9.7 is out.
It can be downloaded from:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-9-7-x86.x86_64.run
Juan
energyman
07-23-2009, 04:14 PM
yes, and you still need patches for 2.6.29 and 30.
cruiseoveride
07-23-2009, 05:35 PM
yes, and you still need patches for 2.6.29 and 30.
yes, and ATi still sucks Nvidia's balls
PuckPoltergeist
07-25-2009, 04:17 PM
Try this (for dkms):
diff -Nru fglrx-8.620.orig/firegl_public.c fglrx-8.620/firegl_public.c
--- fglrx-8.620.orig/firegl_public.c 2009-07-07 23:35:39.000000000 +0200
+++ fglrx-8.620/firegl_public.c 2009-07-08 00:54:08.155793160 +0200
@@ -165,6 +165,7 @@
#include <linux/string.h>
#include <linux/gfp.h>
#include <linux/swap.h>
+#include <linux/pid.h>
#include "firegl_public.h"
#include "kcl_osconfig.h"
@@ -1292,7 +1293,7 @@
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
p = find_task_by_pid( pid );
#else
- p = find_task_by_vpid( pid );
+ p = pid_task( pid, PIDTYPE_PID );
#endif
if (p)
{
This won't work cause find_task_by_vpid needs pid_t as parameter whereas pid_task takes a pointer to a struct pid. AMD has to fix this inside the binary blob an move to struct pid instead of pid_t.
This won't work cause
Well it just made it start for a while, then it crashed ;) I just looked how this is used in current kernel, but i have no idea how to fix it correctly. Hopefully ati does for next driver.
PuckPoltergeist
07-26-2009, 09:08 AM
Well it just made it start for a while, then it crashed ;) I just looked how this is used in current kernel, but i have no idea how to fix it correctly. Hopefully ati does for next driver.
The right (and only) way to fix this, is to move to struct pid instead pid_t. There is no other solution since non GPL-code can't map pid_t to struct pid. The responsible function (find_pid_ns) is EXPORT_SYMBOL_GPL.
vBulletin® v3.8.4, Copyright ©2000-2010, Jelsoft Enterprises Ltd.