Announcement

Collapse
No announcement yet.

AMD Catalyst 13.2 Beta Driver For Linux Released

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

  • #21
    Heck, late kernel/Xorg support is the least for me. Compared to things slugginess and lag I often have on the desktop(it's MUCH less with radeon). Pretty much everything fullscreen and hardware accelerated is glitched. Right clicking on a fullscreen youtube video temporarily glitches up graphics for a moment and then no right click menu. Sometimes there is, but it's invisible. In fact when running a game or anything that combines fullscreen and hardware acceleration(flash in chrome). I can't see anything else other than the fullscreen thing, no matter what I do, except in between glitchy graphics when I alt-tab, activate a hot corner, etc, It's really annoying .. You can see it happened, but you're still shown the fullscreen window. Sometimes by moving the cursor around I can see the windows in expo mode when it happens due to the corresponding hot corner, and then a glitched texture makes a sort appearance before the fullscreen window is again falsely displayed, since I interact with the expo mode. Same with workspaces hot corner and more. Pressing media keys also glitches the graphics temporarily while the sound icon is displayed when in a game/fullscreen-accelerated-window.
    So recently I started using the Gala window manager. Very fast, fluid, smooth. Even the previous bug didn't happen in many cases. BUT screenshots would show some random image of another window not in forefront or just background(some buffer madness must be going on there), transitions when logging in/out seem very glitchy(glitchy textures like usual), games/fullscreen-accelerated-windows present me with a nice purely black screen and similar goodness.
    So I found a way to cure these bugs surprisingly! Yeah, you guessed it! "sudo cp /usr/bin/gala /usr/bin/gnome-shell && gnome-shell --replace".(WTH?)
    You might say "what?". People more familiar with Catalyst may understand though. Catalyst works very well in general(as described previously ..) so many application specific hacks are used(I could say tweaks, fixes, but hacks is probably more correct). It appears that it severely breaks mutter based window managers, so more hacks were added for that(who would guess?). But Gala (and apparently Cinnamon) are not on the list to get "fixed" and miss on all that goodness resulting to mentioned bugs. But by using an appropriately named executable file I was able to activate them. So here's the thing. While all the bugs that mentioned for Gala were gone now, all the previously mentioned issues suddenly appeared... xD
    Now I so hope power management for radeo comes about soon ... :/
    I mean seriously .. And it's that way in many different version of many different distributions, but not with radeon(I have other issues there though, mostly my laptop emitting amounts of thermal energy similar to a nuclear reactor when just web browsing etc).
    Why don't they fix this kind of stuff? And just apply more application specific hacks that bring other problems? Can't they make a driver work right? UNIVERSALLY! NO APPLICATION SPECIFIC HACKS! It's pretty obvious that the driver behaves very differently for different kinds of apps, like games, window managers and other apps. I understand performance profiles .. But this? I mean application may not work AT ALL without the hacks, while they would under ANY other platform.(by platform I mean other proprietary or open drivers)
    I mean, even certain OpenGL commands just fail if not issued in certain ways/order, while they work on the other drivers.
    Instead we get new performance profiles and a graphics corruption fix which isn't really a fix since it doesn't solve the issue, but causes another one apparently ..
    Thanks AMD! :P
    Yeah, I know, they care for "workstations". I don't recall my laptop saying workstation anywhere though, and whatever AMD card I saw/bought seemed to advertise games on it, not render farms or whatever ..

    Anyways, hopefully, good times are ahead for the open radeon driver. But for me, it's just not there yet .. :/
    Should I add, Elementary OS plans to blacklist fglrx from Jockey .. xD
    They're not very wrong I think .. :/

    Whoops, wall of text! It's probably due to my love for AMD!
    Seriously, I like AMD, but just fix the damn drivers .. -.-
    Please?

    Comment


    • #22
      Originally posted by Vim_User View Post
      Arch includes patches for kernel 3.7 and 3.8: https://aur.archlinux.org/packages/catalyst/

      I can tell you what is going wrong: AMD's driver policy is pathetic. The latest officially supported kernel that is still supported by the kernel developers is 3.4. Patches to make it work with newer kernels seem to be trivial, but nonetheless AMD is not able to integrate them.
      Want to try the improved drivers of kernel 3.7? The improvements in btrfs? Want to get rid of problems that are solved in newer kernels? Or even try the AVX support for your new CPU? Nope, AMD does not want you to, as long as you are not using the free drivers, which lack proper power-management, video-decoding and don't fully support other features of your GPU.

      I run Slackware, it is even less patched than Arch.
      Then switch to Arch or use Ubuntu with a slightly older kernel. I don't blame AMD for not immediately supporting a brand new kernel. If I was running a business I wouldn't either.

      Comment


      • #23
        People, calm down with the "why u ship the latest patchorz!?!?". It's simple: it's called validation and testing.

        If they haven't tested it properly yet, how do they know it won't eat your machine, or cause some big issue about corrupting data, etc.
        It's not just "ship patches and pray". They could include the patches behind a non-default switch like --please-eat-my-hard-drive or something like that, but otherwise it's a good thing they don't rush to include untested stuff.

        Comment


        • #24
          Originally posted by Rigaldo View Post
          It appears that it severely breaks mutter based window managers, so more hacks were added for that(who would guess?).
          You even doesn't assume there may be bug in application, but not in the driver, don't you?
          Originally posted by Rigaldo View Post
          Can't they make a driver work right? UNIVERSALLY! NO APPLICATION SPECIFIC HACKS!
          Sure! Since day when all applications developers begin write bug-free code.
          Originally posted by Rigaldo View Post
          I mean, even certain OpenGL commands just fail if not issued in certain ways/order, while they work on the other drivers.
          There is thread about this.

          Comment


          • #25
            Originally posted by nirvanix View Post
            Then switch to Arch or use Ubuntu with a slightly older kernel. I don't blame AMD for not immediately supporting a brand new kernel. If I was running a business I wouldn't either.
            I will not switch to Arch (unstable by design) or Ubuntu (buggy as hell and only interested in vendor lock-in) just because AMD thinks that in the 13.2 Beta (read year 2013, February) they don't have to support latest stable kernel, released 2012. This is far from immediate support and this is also not about business use (you wouldn't run a new kernel on a business OS anyways, don't you think?).

            I will make the obvious switch, AMD doesn't support me, I don't support them. Future money will go to Intel/Nvidia (Nvidia by the way has already support for xserver 1.14 and kernel 3.7 and even xserver 1.13 in their legacy drivers) for sure, but as long as my systems are not obsolete to me I will further complain about AMD's crappy driver policy.

            Comment


            • #26
              Originally posted by RussianNeuroMancer View Post
              You even doesn't assume there may be bug in application, but not in the driver, don't you?
              Sure! Since day when all applications developers begin write bug-free code.
              There is thread about this.
              I think I can assume that something is not an application specific bug under the following conditions(because I first assumed I was faced with application specific bugs):
              -Other people with different hardware/driver configurations are unaffected.
              -I am unaffected when using a different driver on the same machine(radeon in this case).
              -I am unaffected when using the program in a different machine that runs neither Catalyst or has an AMD graphics adapter.

              I think it's pretty safe to assume it is a driver bug after this? Because yes, I did test all that. Did you honestly think the first thing that came to my mind that I could blame was the driver? On the contrary, it took my a while and some testing to arrive to such a conclusion. I have an older laptop with an NVIDIA GPU where I never worried about any of those while I used it. Neither was there a problem when testing on machines with Intel graphics. Neither on the same machine with the radeon driver. Am I so unlucky? On multiple different version of OSes and drivers?
              Of course I try to run the latest version of Catalyst every time(13.1 now).

              And put just a bit of thought on this, how were there huge differences on how a window manager behaves by just changing its name if its not application specific hacks done by the driver?
              Hint: The application doesn't behave differently because it checks its own name.

              Also I've read blog posts from at least one window manager developer(compiz) referencing to that. How come it be only on AMD that something like this happens?
              Why is "Proper Catalyst support" one of the new features of KDE 4.10? I never saw "Proper nouveau/radeon/intel/nvidia support" anywhere.
              Intel, nouveau, nvidia and radeon are probably buggy, but fglrx isn't I guess .... That's why the latter often requires special care from applications.

              If you have evidence suggesting otherwise I'd gladly listen, but to automatically assume the application is buggy doesn't seem right to me.

              Comment


              • #27
                Originally posted by Rigaldo View Post
                I think I can assume that something is not an application specific bug under the following conditions(because I first assumed I was faced with application specific bugs):
                -Other people with different hardware/driver configurations are unaffected.
                -I am unaffected when using a different driver on the same machine(radeon in this case).
                -I am unaffected when using the program in a different machine that runs neither Catalyst or has an AMD graphics adapter.

                I think it's pretty safe to assume it is a driver bug after this?
                Gnome Shell bug was under same conditions but that was application bug at the end.

                I have an older laptop with an NVIDIA GPU where I never worried about any of those while I used it. Neither was there a problem when testing on machines with Intel graphics. Neither on the same machine with the radeon driver. Am I so unlucky? On multiple different version of OSes and drivers?

                That's why the latter often requires special care from applications.
                Again, there is thread about this.

                Comment


                • #28
                  Originally posted by RussianNeuroMancer View Post
                  Gnome Shell bug was under same conditions but that was application bug at the end.

                  Again, there is thread about this.

                  ONE bug on Gnome Shell was indeed application specific. Does that mean much against hordes of bugs that have been resolved(or not) by Catalyst applying hacks too applications(easily provable) and even then application applying hacks back at Catalyst cause it wasn't enough?
                  Still fails to answer how a bug can happen only on Catalyst. An even behave differently with the same Catalyst under different circumstances(like different application name so no hacks are applied on it).

                  And thanks for the thread link, but I've read this thread a long time ago, and to day it still doesn't look much different.

                  Btw, the bug comment you listed reads as follows:

                  [email protected] 2012-04-24 02:42:10 CDT
                  thanks for the stack traces. they were really useful.

                  we changed our implementation for "#version" which should fix the crash.
                  "
                  According to glsl spec, version 4.20, 3.3 Preprocessor, Page 13,
                  The #version directive must occur in a shader before anything else, except for
                  comments and white space.
                  So the original operation was right. But NV's behavior looks like:
                  a. only preprocessor codes could be placed before "version"
                  b. pragma and extension can't be placed before "version"
                  c. the codes between "if" "else" "endif" can't contain no-preprocessor codes.
                  "
                  Doesn't that mean that AMD changed their implementation of GL Shading Language on Catalyst?(At least for Gnome Shell)
                  Maybe I am missing something, but why did they do that? If they are correct, Gnome devs should fix that(and even AMD devs could submit a patch simply getting the version line on top if they wanted to fix it themselves), but instead feed a vicious cycle of hacks on top of hacks?

                  Comment


                  • #29
                    Originally posted by Rigaldo View Post
                    If they are correct, Gnome devs should fix that
                    Soo... maybe there is Gala or/and Cinnamon issue? Maybe you have to contact with Gala and Cinnamon developers and ask them to look into this issue? If there is really driver issue, they can say what exactly fail, contact with Catalyst Team and ask for fix - that will be easier and faster solution for everybody, isn't it?
                    Originally posted by Rigaldo View Post
                    and even AMD devs could submit a patch simply getting the version line on top if they wanted to fix it themselves), but instead feed a vicious cycle of hacks on top of hacks?
                    Gnome Shell developers already fix that but Catalyst Team probably need to get doesn't crash previous builds of Gnome Shell (that doesn't include fix). Also Catalyst developers is writing patches for KWin (Jammy Zhou) - that what called "proper support of catalyst" on Phoronix.

                    Comment


                    • #30
                      Rigaldo,
                      RussianNeuroMancer,

                      The problem you guys are talking about here is known among Cinnamon users who have Radeon cards, and I'm one of them. I've reported this bug long ago and still have no answer from developers, but thanks to George we now know that renaming cinnamon/gala to "gnome-shell" fixes most of the problems, and I think that might help developers in their work.
                      BTW, Rigaldo, are you the one who posted this in bugreport I mentioned above? If not, then at least you know where to look for the additional information

                      Comment

                      Working...
                      X