Announcement

Collapse
No announcement yet.

AMD Puts Out An OpenGL 4.2 Linux Driver

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

  • #21
    Originally posted by Kirurgs View Post
    I'm with mirv
    I have not encountered any big problems for a year at least. When I switched from nvidia to amd, for me it was getting better and better. I have nice story about PM issues with nvidia for 2 years on nvnews... No fix... AMD is actually done a lot better job for me than nvidia.
    No need to blame AMD when there is no proof that actually they are responsible for the bug.

    The big one to me seems to be gnome-shell slowness and corruption, KDE 4.7 works perfectly for me or I'm just lukcy (why not others?). I have mobility 3650, works nice, really. No issues with the driver.

    Of want to blame anyone, get a proof and blame, that's the rule, else it's speculation and FUD
    In the KDE Plasma Workspaces 4.7 we introduce new Compositing backends/modes in our Compositor. Lately I noticed that there is some misunderstanding on what are the differences between the modes, w…


    The legacy backend is used automatically for all drivers not supporting at least OpenGL 2.0 and the fglrx driver.
    So put this in .bashrc

    export KWIN_DIRECT_GL=1

    save it, then log out and log in.

    That will force FGLRX to get the new/modern backend which it can only barely handle. With vsync or tear-free desktop on it's too slow to use, it becomes usable by turning those off, then you just have tearing and the fact that any video game you load will be garbled.

    It seems that FGLRX depends on the legacy fixed function OpenGL 1.x backend, which is also how Compiz works, or else it just totally falls apart. If not immediately, then as soon as you try to load a compositing window manager supporting OpenGL 2 and another OpenGL application.

    Seeing as the problem is hardly unique to GNOME Shell and KDE is just feeding FGLRX an obsolete backend to make it happy, I'm going to suggest that AMD's driver is simply broken. Also, as mentioned before, Firefox in OpenGL mode with FGLRX renders upside down and backwards. I got a screenshot of that btw.



    Then if you tell Chrome to ignore their OpenGL blacklist and force OpenGL compositing and canvas on, it will randomly panic the kernel.

    I think as time goes on you'll see more and more projects simply ignoring FGLRX because it's too broken to even deal with. Firefox and Chrome even specifically say that it is the fault of FGLRX and there's nothing reasonable that they can do about it.

    Comment


    • #22
      Originally posted by jrch2k8 View Post
      well it is an fglrx issue since nvidia blob, nouveau, intel dri and r600g run the opengl2 path in kwin perfectly but my 4850x2 with catalyst any version (properly installed) just get really funky here, is not like i care too much on my side since i trully love r600g

      btw i check catalyst not for masochist (you need to be) but because i got some clients i can't convince to abandon firepro for some good supported quadro cards, so i have to check from time to time if fglrx is stable to avoid shoot myself in the foot offering me to upgrade their drivers
      I have yet to see a single thing I use work right with Catalyst for Linux. I don't know how anyone claims it has progressed. Well granted, it no longer freezes up the entre desktop when you resize a window, but beyond that they don't fix anything at all.

      Comment


      • #23
        Oddly enough -- having just released a private beta build of our game today -- we've had _less_ issues on AMD GPUs/drivers than NVIDIA's. The game runs beautifully on OS X, Linux, and Windows using a range of low- to high-end AMD hardware and even Sandy Bridge GPUs, but occasionally stutters a bit on every machine with an NVIDIA GPU of any kind we've tried, including a fairly beastly GTX 460 w/ Windows 7. Craziness, right?

        Comment


        • #24
          Originally posted by Luke_Wolf View Post
          Actually as far as I could tell, AMD is pimping out both linux and windows, such as here http://sites.amd.com/us/business/sof...es/redhat.aspx And if you want to really ask questions about advertising, why the hell is it that until I set up my DNS black hole, whenever I would go to any Linux site I'd see Microsoft Advertisements? I've seen more microsoft advertisements on linux sites than anywhere else.
          Because advertisers aren't going to advertise to you for things you already have. If you're running Windows you don't need Windows advertisements. Microsoft has a lot of money, so you'll only be really slammed with Windows advertisements if you're running a non-Windows OS.

          Comment


          • #25
            Originally posted by elanthis View Post
            Oddly enough -- having just released a private beta build of our game today -- we've had _less_ issues on AMD GPUs/drivers than NVIDIA's. The game runs beautifully on OS X, Linux, and Windows using a range of low- to high-end AMD hardware and even Sandy Bridge GPUs, but occasionally stutters a bit on every machine with an NVIDIA GPU of any kind we've tried, including a fairly beastly GTX 460 w/ Windows 7. Craziness, right?
            Must be the game, and/or optimisations.

            Comment


            • #26
              @DaemonFC:

              I suspect the fglrx drivers have an issue with the shaders being used by KWin. This is a two-fold problem I've encountered before - fglrx is very picky about the shaders, and doesn't enjoy things when they deviate from the spec, however many people _do_ deviate from the spec. On the one hand, the deviation is bad, on the other, fglrx should be aware of any common issues and at least flag a warning message (though again, it's up to the developers to take note of such warning messages).
              I personally don't mind it being very strict - it forces people to things the Right Way(tm) and should mean that when people do, fewer driver work arounds are required by both application and driver developers. There's a reason for there being a spec after all.
              (If, by the way, you want a specific example with OpenGL 3.3 shaders: the floating point precision must be explicitly stated in fragment shaders according to the spec. The fglrx drivers at least used to not work if you didn't do this, but nvidia's blobs ran without even giving a warning message.)

              That's all a guess however, and I've no interest in debugging KWin, so that's all it will remain, but it's a good example of why things are quite so black and white as you make out.

              Comment


              • #27
                Originally posted by PreferLinux View Post
                Must be the game, and/or optimisations.
                If you mean the game is hitting some particular bug in the driver that most games don't, then yes of course. It's hardly the first driver bug we've found in NVIDIA's drivers, and you don't write much game (or graphics) code without a good dose of work-arounds for bugs you can't fix (_especially_ in OpenGL code). NVIDIA's drivers are far from perfect; that's what makes it so very sad that it's so accurate to state that their drivers are by far the best.

                Comment


                • #28
                  Originally posted by elanthis View Post
                  If you mean the game is hitting some particular bug in the driver that most games don't, then yes of course. It's hardly the first driver bug we've found in NVIDIA's drivers, and you don't write much game (or graphics) code without a good dose of work-arounds for bugs you can't fix (_especially_ in OpenGL code). NVIDIA's drivers are far from perfect; that's what makes it so very sad that it's so accurate to state that their drivers are by far the best.
                  (ok, I'm starting to drift off topic about opengl4.2, but....)
                  Ugh, how true that is. And I'm no seasoned game developer, though I'm not exactly new to OpenGL. As I don't have any nvidia cards (other than a little ion in a htpc, so it doesn't really count for these purposes), most of my stories are from fglrx, or ye old r200. Display list problems, problems with updating compressed textures on the fly (must update blocks in a specific order, or it doesn't work - I still have that fix in from about 3 years ago, though I don't think it's required any more), "fun" with shader versions, and that's even before you start going across different hardware generations. Then of course if you're using extensions that most people have anyway, they often put their own little twists into them.
                  To try bring things back on topic a bit, this is why it's a good thing that AMD and nVidia both have OpenGL 4.2 beta drivers out - people can test them, find any problems, and both companies can hopefully have more stable versions out soon that won't require work arounds from developers. Now I did say hopefully....

                  Comment


                  • #29
                    Originally posted by mirv View Post
                    @DaemonFC:

                    I suspect the fglrx drivers have an issue with the shaders being used by KWin. This is a two-fold problem I've encountered before - fglrx is very picky about the shaders, and doesn't enjoy things when they deviate from the spec, however many people _do_ deviate from the spec. On the one hand, the deviation is bad, on the other, fglrx should be aware of any common issues and at least flag a warning message (though again, it's up to the developers to take note of such warning messages).
                    I personally don't mind it being very strict - it forces people to things the Right Way(tm) and should mean that when people do, fewer driver work arounds are required by both application and driver developers. There's a reason for there being a spec after all.
                    (If, by the way, you want a specific example with OpenGL 3.3 shaders: the floating point precision must be explicitly stated in fragment shaders according to the spec. The fglrx drivers at least used to not work if you didn't do this, but nvidia's blobs ran without even giving a warning message.)

                    That's all a guess however, and I've no interest in debugging KWin, so that's all it will remain, but it's a good example of why things are quite so black and white as you make out.
                    Mesa is pretty darned strict and the open source drivers using it can handle GNOME Shell, KWin 4.7, Firefox with OpenGL compositing, and Chrome with OpenGL compositing. I'm sure there's not some vast conspiracy to simply break AMD's "perfect" (hah) proprietary driver. The amount of stuff that just doesn't work at all with FGLRX loaded is pretty compelling.

                    For whatever reason (Should I care? I'm just the victi....errrrr....customer of an AMD card that won't run the applications I want it to with their driver.) It gets a little old loading FGLRX when I want to play some intense game and radeon when I just want my desktop to work right. Someone needs to get their act together.

                    Comment


                    • #30
                      Originally posted by DaemonFC View Post
                      Mesa is pretty darned strict and the open source drivers using it can handle GNOME Shell, KWin 4.7, Firefox with OpenGL compositing, and Chrome with OpenGL compositing. I'm sure there's not some vast conspiracy to simply break AMD's "perfect" (hah) proprietary driver. The amount of stuff that just doesn't work at all with FGLRX loaded is pretty compelling.

                      For whatever reason (Should I care? I'm just the victi....errrrr....customer of an AMD card that won't run the applications I want it to with their driver.) It gets a little old loading FGLRX when I want to play some intense game and radeon when I just want my desktop to work right. Someone needs to get their act together.
                      I see you basically ignored everything I wrote....

                      Comment

                      Working...
                      X