Announcement

Collapse
No announcement yet.

AMD Releases Catalyst 9.6 For Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic AMD Releases Catalyst 9.6 For Linux

    AMD Releases Catalyst 9.6 For Linux

    Phoronix: AMD Releases Catalyst 9.6 For Linux

    AMD has pushed out a new Catalyst driver update for Linux users this afternoon. The two new features in this release, as mentioned by their release notes (PDF), is support for new Linux distributions and MultiView support for Radeon hardware. The distributions now officially supported by the Catalyst 9.6 Linux driver is SuSE Linux Enterprise Desktop 11 and early Red Hat Enterprise Linux 4.8 support...

    http://www.phoronix.com/vr.php?view=NzMyOA

  • PuckPoltergeist
    replied
    Originally posted by Kano View Post
    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.

    Leave a comment:


  • Kano
    replied
    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.

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by Kano View Post
    Try this (for dkms):

    Code:
    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

    Leave a comment:


  • cruiseoveride
    replied
    Originally posted by energyman View Post
    yes, and you still need patches for 2.6.29 and 30.
    yes, and ATi still sucks Nvidia's balls

    Leave a comment:


  • energyman
    replied
    yes, and you still need patches for 2.6.29 and 30.

    Leave a comment:


  • kubunteando
    replied
    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...x86.x86_64.run


    Juan

    Leave a comment:


  • cutterjohn
    replied
    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. [EDIT2] 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. [/EDIT2]

    PPAs: I've resorted to that for wine to get GW running, maybe I should try that PPA xorg. Which one is it BTW? [EDIT3] 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. [/EDIT3]

    There's also this winebug report, labelled as yet another catalyst bug:
    http://bugs.winehq.org/show_bug.cgi?id=18794
    [EDIT]
    9.6 seems to have partially fixed this bug, but not completely.
    [/EDIT]

    [EDIT4]
    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.)
    [/EDIT4]
    Last edited by cutterjohn; 07-14-2009, 09:10 AM.

    Leave a comment:


  • JeanPaul145
    replied
    Originally posted by cutterjohn View Post
    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.

    Leave a comment:


  • bridgman
    replied
    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...

    Leave a comment:

Working...
X