Announcement

Collapse
No announcement yet.

AMD Catalyst 9.11 For Linux Released

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

  • #31
    I have a question, mostly for the devs.

    How much effort is putting into developing and stabilizing new opengl extensions? Well actually I'm satisfied with fglrx, but I have the impression that the more advanced opengl features is in a bad shape.

    Right now there isn't any advanced opengl app in linux, besides maybe unigine and wine trying running advanced games. I just tried using fglrx with wine and I got a lot of games up and running. But some games, which should run ok cf. winehq.org, doesn't work / are slow or have graphic artifacts.

    Well I went in #winehq asking why fglrx didn't like wine or vice-versa. A wine direct3d developer said, that fglrx still have a lot of bugs in the more advanced opengl areas. But it should actually support wine as good as nvidia, but the support is just buggy. He told me that the more advanced windows apps makes wine trying to call advanced opengl code-paths. Those advance code path is very buggy on fglrx still. Though he noted that the fglrx driver has improved very much lately.

    So will there be more in stabilizing and optimizing the opengl stack?
    Last edited by tball; 11-20-2009, 02:01 PM.

    Comment


    • #32
      I don't remember seeing any OpenGL bug reports filed against newer extensions recently so not sure what the specific issues might be (which makes it hard to *fix* them)...

      ... but "yes the OpenGL support will continue to improve". Most of the 3D stack is shared across multiple OSes, so fixes made for one OS will usually benefit the other OSes.
      Last edited by bridgman; 11-20-2009, 02:38 PM.

      Comment


      • #33
        @bridgman

        Got it.
        Will you care of bugs with a lot of wine fixme's and console spawn?
        Or is there a specific way to get debugging informations?

        Comment


        • #34
          Well you need at least a nv gpu to crosscheck it is a fglrx problem

          Comment


          • #35
            Originally posted by tball View Post
            @bridgman

            Got it.
            Will you care of bugs with a lot of wine fixme's and console spawn?
            Or is there a specific way to get debugging informations?
            Most of the improvements have come when the Wine devs take the problem from "Windows app ABC does something bad" to "we expect this OpenGL call to do X but it actually does Y" -- then we either respond with "calling that way has undefined results in the OpenGL spec, but if you called <this> way it would work on everyones HW" or "that's not right, we'll fix it".

            Comment


            • #36
              can someone help me here, i got 9.10 and well got all working not stable ofc but manageable. but with 9.11 well kde4 composite is broken (wierd ja )but the black texture corruption is gone in 2d it seems for now.

              here is my pctested with default clocks too ofc and with windows 7 x64. is not a hardware issue)
              athlon x4 620 cache unlocked @ 3.7ghz
              mobo msi gd-70 ht @ 2.250 ghz
              Radeon hd 4850x2 x 2 aka quadfire (tried with 1 card too ofc)
              kubuntu 9.10 x64 fresh install + update + nothing custom or ppa all is distro repos

              so the thousand dollars question how the [email protected][email protected][email protected] i debug or fix it??

              and plz focus more devs in oss driver to get at least the same lvl of 3d than intel driver, so i can switch and lets this nigthmare behind, i dont wanna be rude but when you have to actually works with a pc. this erratic behaviour is a liver killer, lol 9.9 xv broken + hard lockups. 9.10 3d semi stable, 2d really corrupted but composite fixed it, 9.11 2d no corruption 3d broken. really some QA wont harm anyone, ok maybe is my fault for do the crazy stuff of buying an X2 card and it works fine in x1 cards, i can live with that cuz 1 4850 is powerful enough to work but in that case at least force disable the second chip by default and enabled it only when someone actually tested it in next releases. for now ill try google, disable all that aticonfig let me, and ofc gdb my 3d apps once again to try to trace where is the broken stuff, and make a script that do this automatic so less trauma every "release"

              UPDATE:
              after more testing and disabled everything i could, well stream is broken, flash is broken(especially 10.1 using stream but ok is beta but well in nvidia/intel works just fine)(flash suddenly stop rendering and hang the browser but the audio keeps playing), crossfire is broken aka every 3d app using crossfire after few mins black screen then deathlock, i suspect kernel panic but well i cant see it cuz everything including keyboards just dies, composite like i said before keep broken even without crossfire, xv have less tearing but compared to nvidia/intel is very noticeable (maybe im just too picky here, not the big deal), 2d works fine for first time since i remember, wine is ***working*** first time since i remember but ofc it hangs few mins later if i dare to activate crossfire, so no hardcore games in wine for now
              Last edited by jrch2k8; 11-23-2009, 12:47 AM.

              Comment


              • #37
                Originally posted by bridgman View Post
                Most of the improvements have come when the Wine devs take the problem from "Windows app ABC does something bad" to "we expect this OpenGL call to do X but it actually does Y" -- then we either respond with "calling that way has undefined results in the OpenGL spec, but if you called <this> way it would work on everyones HW" or "that's not right, we'll fix it".
                Extending John's comments somewhat.

                Most wine devs use NV. So the open-to-interpretation parts of the spec opt for the NV behaviour. This paired with DX to OGL being a black art itself results in something akin to...

                wine+game have an affinity to NV. It might be that the game doesn't work under ATI, but that is most likely that it has never been tested against ATI by a dev, so the NV behaviour becomes the defacto path for wine. People hold then look at the NV+wine pairing as working perfectly, and ati+wine as being broken. The only variable changing is the vendor, so it is possibly a valid (albiet vastly simplified, nearly naive) assumption to make.

                The reality is that the NV bugs and the wine bugs become mutually compatible and fit together nicely. The ATI bugs and the wine bugs simply don't play nicely together. A wine bug may be present because of a behaviour with NV, where without that behaviour wine is actually misbehaving and the ATI driver is actually correct.

                This doesn't make the pairing any easier to handle, nv+wine just works better. But until the wine devs have a representative mix of hw to the market, it will be a slow, painful path to stability.

                Matt

                Comment


                • #38
                  Except that I am running Fedora 10

                  Originally posted by energyman View Post
                  just unbreak your xorg-server with the backclear patch. 2d will be very pleasant afterwards.
                  Fedora 10 is so old that it is within days of becoming completely obsolete. And 9.11 is brand spankin' new... In other words, this "backclear patch" has been 'out there' for a long, long time...

                  Why is fglrx consistently behind the curve when it comes to X support? It doesn't even do EXA yet, either!

                  Exactly who is fglrx's "main customer", when so many desktop Linux users are scratching their eyes out in frustration at its lack-lustre performance?

                  Comment


                  • #39
                    I believe the backclear patch is pretty recent. It's the "no backfill" patch that has been around for years and was a standard part of most distros until it was taken out of the X server this year.

                    The "main customer" for fglrx is still the 3D workstation market, which tends to run on enterprise distro releases with older X servers without the font caching fixes which make EXA useable. They would generally not be able to make use of EXA and would not see the unminimizing delay anyways, since it only occurs when a compositor is enabled.

                    Comment


                    • #40
                      I don't quite follow how anyone looking for a high end linux 3D workstation would want to buy ati.

                      I do have an IBM T60P which does fit that profile and did scientific visualization on it (with a lot of polygons) and even the then brand new radeon r500 dri was a lot faster than fglrx, which was plainly unusable.

                      Comment

                      Working...
                      X