Announcement

Collapse
No announcement yet.

AMD Releases Catalyst 9.6 For Linux

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

  • 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?
    Last edited by mklean; 06-18-2009, 01:22 PM.

    Comment


    • Originally posted by Melcar View Post
      Well, the last "stable" WINE release *is* 1.0.1.
      1.1.23 broke a lot of Windows installers for me; almost none of my games can install. 1.1.18-1.1.21 seem to be the best revisions.
      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

      Comment


      • Originally posted by Bitmasker View Post
        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.

        Comment


        • Originally posted by mklean View Post
          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:
          Code:
          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
          Code:
          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.
          Last edited by cutterjohn; 06-19-2009, 11:02 AM.

          Comment


          • Originally posted by NeoBrain View Post
            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!

            Comment


            • 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.
              Last edited by mklean; 06-19-2009, 11:31 AM.

              Comment


              • Originally posted by energyman View Post
                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.

                Comment


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

                  Comment


                  • 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

                    Comment


                    • Originally posted by energyman View Post
                      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.

                      Comment


                      • 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

                        Comment


                        • Originally posted by RealNC View Post
                          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.
                          Last edited by Darksurf; 06-19-2009, 11:29 PM.

                          Comment


                          • guys, calm down. But, Darksurf, energyman is right. If we follow your way, then the /usr/lib/libGL.so symlink will have a big trouble in compiling new x-server, mesa, libdrm etc, because the portage will delete the symlink at the switching OpenGL library stage and cause an error in compiling.

                            Comment


                            • Anyone have a patch for opensuse 11.2 [?], it uses kernel 2.6.30.

                              Comment


                              • Just thought I might give my experience to all the complainers around here.

                                My first ATI 4850 died for some obscure reason, and since I heard that the NVIDIA UNIX driver was so much better than the ATI one, I replaced it by a 9800GT (big mistake in terms of performance over the 4850 i know, but the price tag of the GTX260 is way higher...).

                                So i came back home, and installed the NVIDIA driver. So far so good.
                                I'm using Slackware 12.1 with 2.6.27, compiz with rox-filer. I noticed no real difference at first since I had no real problem with the latest ATI apart from the openGL apps. XV was fine with both drivers (mplayer patched to make it work with compiz), compiz too.

                                At some point, using the scale compiz module, hard freezes came to happen. Bad news indeed, since I figured out that the NVIDIA team, despite numerous reports of the same error, just isn't ready to fix it for some obscure reason (to my knowledge at least). The NV forum is also loaded with unhappy users (but none of them are yelling that ATI is better, for some reason ).

                                I switched back to the 4850 because it's much better in Dos Games compared to the 9800 GT (even GTX). The driver seems fine with me in Linux overall, I can watch 1080p HD movies without any performance issue in Compiz, I can play OpenGL games too. Sure the latest kernel isn't supported, and I understand it might be frustrating for the latest develoment (which ones, out of curiosity ?). But, it does mostly what it is supposed to do, isn't it ?

                                Things are going better now, and will keep going this way I'm sure.
                                Grass is always greener next door.

                                Enjoy!

                                Comment

                                Working...
                                X