AMD Releases Catalyst 9.6 For Linux

[Darksurf]

Gentoo isn't Slackware. You aren't supposed to do things by hand in Gentoo. There are tools you should use, or you break the system. So your instructions are not for everyone. If you don't know how to unbreak the system, don't follow them. If you know how to unbreak your system, I suppose you didn't need those instructions in the first place

You do have a point, but any linux system allows you to do things by hand. Thus the freedom and flexability of linux. You don't always need to use the tools, they are helpful, yet sometimes they do hinder your possibilities. Gentoo and Slackware users should usually be advanced users. Many novice users use ubuntu (no insult intended) and have tools to do these things for them, but some advanced users want to push the limits of what the tools allow. Improvisation is then used to acquire what is wanted and allows those who are yet advanced to learn.

Slackware is like linux bootcamp. You do EVERYTHING by hand so you understand linux and how the file structure, files, etc work. So if something goes wrong you know how to fix it without GUI and/or tools and sometimes you just make your own tools and scripts. That is how i learned. I'm sure gentoo users can handle themselves just fine with the basic knowledge of how linux and the files work. And novice users of Gentoo can use Sabayon (its what I use). It has a binary package manager as well as portage and they are compatible with each other. Thus allowing advanced users and novice users to use what they prefer and giving an OOTB (out-of-the-box) experience.

But again, you do have a point. Those not of an advanced nature wouldn't be happy with the results unless they had help.

[RealNC]

Gentoo isn't Slackware. You aren't supposed to do things by hand in Gentoo. There are tools you should use, or you break the system. So your instructions are not for everyone. If you don't know how to unbreak the system, don't follow them. If you know how to unbreak your system, I suppose you didn't need those instructions in the first place

[Darksurf]

oh yeah? skipping 'eselect opengl set ati' and then forcing the ati libs into the system by the installier is simply braindead. If you can't even understand why that is stupid you shouldn't even use a gentoo based system. Harsh, yes. But true.

If I must remind you. In gentoo, opengl is managed by different diurs for the implementations. eselect then sets the correct symlinks.

So far, so good. This gives a lot of flexibility. And cleanliness.
If you use the installer, it writes the files where the symlinks should go. Suddenly you can not switch around easily (which had to be done for some apps to compile in the past). Suddenly you have crap not managed by any package manager in the system.
Pure idiocy.

My my, is flaming the only thing your good at? I used slackware for 4 years and never had the need for a package manager to do my work for me. R you saying that you cannot manage your own computer without the help of a package manager or a GUI? If you cannot do this you have no right to ridicule me. at least I made an effort instead of crying like some of your friends. You make a mountain out of a mole hill. These things are easily fixed. Quit your crying.

Instead of flaming, help others. Ebuild manifest is one way to do things, ebuild digest is the way i've been doing it for a couple years now. I've had no problems and it works fine. Don't see what your complaint is there.

Also, you did a good job on the ebuild, just needed a little TLC for some of us so I gave it a little update for the 2.6.30 kernel users
and those who use Xen. I'm not trying to show you up or anything, I'm just out to help.

http://www.megaupload.com/?d=ZY31Q2ZK

This should work for both 2.6.29 and 2.6.30.

cd and extract in /usr/portage/x11-drivers/ati-drivers
ebuild ati-drivers-8.624.ebuild manifest (yeah, it works too)
emerge ati-drivers
eselect opengl set ati

Energyman, Thanx for a working ebuild. Gentoo is still kinda new to me. I've used Slackware most my life. No need to be nasty, we can all be nice and help out each other without flaming.

[cruiseoveride]

This driver is pure evil. Look at how otherwise sane people are now ready to kill each other.

By the way, i got the sucker working on ubuntu 9.04 x86_64, with kernel 2.6.28.13

[energyman]

oh yeah? skipping 'eselect opengl set ati' and then forcing the ati libs into the system by the installier is simply braindead. If you can't even understand why that is stupid you shouldn't even use a gentoo based system. Harsh, yes. But true.

If I must remind you. In gentoo, opengl is managed by different diurs for the implementations. eselect then sets the correct symlinks.

So far, so good. This gives a lot of flexibility. And cleanliness.
If you use the installer, it writes the files where the symlinks should go. Suddenly you can not switch around easily (which had to be done for some apps to compile in the past). Suddenly you have crap not managed by any package manager in the system.
Pure idiocy.

[Darksurf]

I hope nobody fucked up his system with Darksurf's instructions.

Here:

http://rapidshare.com/files/245611112/ati-drivers.tbz

download that
extract in /usr/local/portage/x11-drivers/
make sure you have ~arch set for ati-drivers
emerge ati-drivers
eselect opengl set ati.

AND DON'T FOLLOW THE INSTRUCTIONS FROM Darksurf!

What the heck are you talking about? I am using the drivers right now with absolutely no problems. This also was for a gentoo based distro.
Cant help it if you aren't linux savy enough to follow simple instructions. If anyone uses a gentoo based distro and would like help with this, I'll gladly give step by step instructions on how to do it.
This way it can easily be removed using portage and upgraded when a better version or ebuild comes out.

Till then, don't tell people not to listen to others just cause you don't understand or cannot follow instructions. If you've got a better ebuild then just say so, no need to attack others.

[mklean]

The texture/crash issue is fixed in wine.git (http://source.winehq.org/git/wine.gi...37c564c4647f5a), at least for the fbo. This problem should be resolved in the 1.1.24.

I ran into the installer bug for GW with 1.1.23. I'll need to back down to 1.1.21. Unfortunately I have a busy weekend ahead so I'm not sure when I will get the time.

[Bitmasker]

Anyone having trouble with Wine 1.23 please try to change HKEY_CURRENT_USER/Software/Wine/Direct3D/OffscreenRenderingMode to either of the methods described at http://wiki.winehq.org/UsefulRegistryKeys.
Wine changed the default value of that thing in 1.1.23 (not sure if the info on the wiki page has been fixed accordingly, yet), so it was expectable that many apps might break (on the other hand, other areas improved with this method).
If things suddenly start working magically, file a bug in the Wine bugzilla, maybe it's just a driver bug or indeed something wrong in Wine.

Despite this being a Direct3D key it allowed my opengl game to load without error under wine 1.1.23 (with OffscreenRenderingMode -> backbuffer). Thanks!

[cutterjohn]

Running Demigod with wine git - fbo using fglrx 9.6 renders DX9 mo-better.

I'll try Guild Wars when I get the chance and confirm if I get the same problems. Cutterjohn, you are running fglrx 9.6?

Yep, just installed it the other day and tried GW with both backbuffer AND fbo. Same results as with 1.1.22.

With backbuffer it crashes right after logging in and apparently finishing the "loading" screens, i.e. when it starts to try to render a play screen.

With fbo, it just bombs out before even getting to the login screen.

I have debugging enabled, and see no complaints of missing .dlls(Had alot of these a long time in in the 0.9x series.) Just some complaints of various shader operations not supported, and then usually a stack error.

This is WITH fbo rendering:

err:ntdll:RtlpWaitForCriticalSection section 0x7e475900 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0018, blocked by 0009, retrying (60 sec)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.

I had the same error under 1.1.22 as well IIRC, however I did not own GW until AFTER I had already gone to 1.1.22.

This is WITH bacbuffer rendering

fixme:win:EnumDisplayDevicesW ((null),0,0x33eb54,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33e228,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33dc28,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33dcb8,0x00000000), stub!
fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found
fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found
fixme:d3d:IWineD3DDeviceImpl_SetDialogBoxMode (0x155740) Dialogs cannot be disabled yet
err:d3d:getColorBits Unsupported format: WINED3DFMT_R32_FLOAT
fixme:d3d:IWineD3DDeviceImpl_SetDialogBoxMode (0x155740) Dialogs cannot be disabled yet
err:d3d:getColorBits Unsupported format: WINED3DFMT_R32_FLOAT
...
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #171:
fixme:d3d_shader:print_glsl_info_log     Fragment shader was successfully compiled to run on hardware.
...
fixme:win:EnumDisplayDevicesW ((null),0,0x15cdad4,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x15cde50,0x00000000), stub!
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #186:
fixme:d3d_shader:print_glsl_info_log     Fragment shader was successfully compiled to run on hardware.
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.

'...' = skipped lines, bunch of complaints about keyboard layout stub, the GLSL error I'm guessing aren't a problem, but then at the end we also see that we die with the same error.

The Steam client itself seems to run OK, which is what I used to install GW.

I read all about the massive installer problems w/1.1.23 AFTER I started looking for "fixes" for my wine problems again. As a matter of fact, I noted that the reports appeared for the SVN version BEFORE 1.1.23 was even released. Seems like someone dropped the ball on that...

Just to be clear I've got catalyst 9.6, Ubuntu 9.04 x86-64(latest updates), and wine 1.1.23 on an MSI GT725-074US.

As to the offscreenrendering mode when defaulted to fbo, as wine does now when there is no registry key entry, crashes just about everything using D3D and the catalyst drivers. Creating the key and setting the value to backbuffer allows many D3D programs to get further, however in my case(s) above(this post, as well as others) I'm right back to where I was before.

Doing a good deal of searching on the winehq.org pages, and the web it seems that the problem is the inability of catalyst to render certain types of textures, and seems to have been deemed a catlyst driver bug by the wine developers.

The reason that I feel like a beta tester is that the only measurable improvement I can see over the catalyst version from 9.2 IS the fix to remove screen flicker when an opengl app was running in a window, and the apparent removal of random screen corruption from 9.5->9.6 or at least I haven't observed it(corruption) yet with 9.6.

I STILL get random video playback freezing X.org(rest of the machine is probably up, but I've got no backup machine ATM to try to ssh in to this one), as the ALT-PRTSCR+RSEINUB reboots ok.

I also STILL get freezes upon waking from sleep/hibernate with compiz/beryl enabled. Other users have reported this as well, IIRC we had a bried discussion about it in the 9.5 thread.

Pretty much the low quality of catalyst X.org drivers have pretty much forced me to give up on using linux + X.org for anything even remotely graphically intensive for fear or hardlocking the machine and/or triggering other wonder catalyst bugs which seem to be endless in number and severe in nature.

[NeoBrain]

I can add some further (anecdotal) evidence of openGL apps under 1.1.23 not working with 9-6 (windows apps crash out, X stays up thankfully)

I've not checked 1.1.21 but have found 1.1.22 to run stably.

Ubuntu 9.04 - AMD64 2.6.28,2.6.30 with fglrx 9-6

Anyone having trouble with Wine 1.23 please try to change HKEY_CURRENT_USER/Software/Wine/Direct3D/OffscreenRenderingMode to either of the methods described at http://wiki.winehq.org/UsefulRegistryKeys.
Wine changed the default value of that thing in 1.1.23 (not sure if the info on the wiki page has been fixed accordingly, yet), so it was expectable that many apps might break (on the other hand, other areas improved with this method).
If things suddenly start working magically, file a bug in the Wine bugzilla, maybe it's just a driver bug or indeed something wrong in Wine.