Announcement

Collapse
No announcement yet.

The Major Open-Source ATI Improvements Over Two Years

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

  • #21
    Originally posted by 89c51 View Post
    video decoders...
    I forgot about that. I'll give it another shot at compiling all the shit that's required one of these days to see if this time I can make it work.

    Comment


    • #22
      I do remain hopeful about the progress of the oss drivers, but they need a lot more work in the power management area.

      These drivers are practically useless to any laptop users until they do something about the power management. Dynpm hardly works and still flickers all the time. Setting to low profile still runs hotter than catalyst and performance is noticeable worse in low profile all the time.

      Comment


      • #23
        These are some great statistics for r300c/g, but when will r600g get the same kind of boost? It's been "coming" for a while now...

        Comment


        • #24
          sigh

          ATI is a lost cause. Especially since that sank a slew of cards to legacy support which hasn't seen action for years. Well, actually the Windows driver did see action. Low and behold.

          v9.3 Ubuntu 9.04/Slackware 12.1/Fedora 8
          http://support.amd.com/us/gpudownloa...2&lang=English


          v10.2 support for Windows 7 64bit
          http://support.amd.com/us/gpudownloa...3&lang=English

          I regret ever getting rid of my tnt2 ultra 10 years ago.

          btw 80% of catalyst is really 40% of Windows.

          Comment


          • #25
            You are being too pessimistic.

            In less than two years, new cards (r600+) went from drawing a triangle to playing Quake4. The only thing that does not work are the Unigine benchmarks (and they are close).

            The older cards (r500-) went from being OK for desktop stuff to surpassing Catalyst in features, and often also in performance.

            I really wonder what some of you people expect.

            Comment


            • #26
              On the feature side I'd also be optimistic. Once we have reasonably stable and fast Gallium3D drivers, for both amd and nv, and they become standard for distributions, I suspect the state tracker business will take off (there are so many ideas/proposals/alpha-stage projects).
              After all, devs are much more enthusiastic about developing stuff that can be used right away (and I don't blame 'em).

              Comment


              • #27
                Originally posted by squirrl View Post
                v9.3 Ubuntu 9.04/Slackware 12.1/Fedora 8
                http://support.amd.com/us/gpudownloa...2&lang=English

                v10.2 support for Windows 7 64bit
                http://support.amd.com/us/gpudownloa...3&lang=English
                Yeah, Windows gets all the attention and the best support. Nothing new there.

                Originally posted by pingufunkybeat
                I really wonder what some of you people expect.
                Even when the OSS drivers have better performance and more features than Catalyst people are going to find something to complain about.

                Comment


                • #28
                  Originally posted by pingufunkybeat View Post
                  I really wonder what some of you people expect.
                  Here's my glewinfo from r600g git master.

                  See all the MISSING?

                  I expect them to become "OK".

                  And then when FooApplication (proprietary, free software, or otherwise) calls them, I want them to work. And for bonus points, it should be fast.

                  That's what I expect.

                  However, I realize that it takes time and manpower and attention to get to that state, so I'm not "complaining" so much as stating what the true end-goal should be. Just as it's unwarranted to go on an internet raging rampage because of inadequate drivers, it's equally unwarranted to sit back on your laurels, content in the bliss that is compiz or mutter, without acknowledging that, as far as we've come, there's a lot of work yet to be done.

                  Comment


                  • #29
                    Originally posted by allquixotic View Post
                    Here's my glewinfo from r600g git master.

                    See all the MISSING?

                    I expect them to become "OK".
                    Mhm. Even the nv blob produces 725 MISSING vs 1764 OK. So it's not really black and white...

                    Comment


                    • #30
                      Originally posted by allquixotic View Post
                      Here's my glewinfo from r600g git master.

                      See all the MISSING?

                      I expect them to become "OK".

                      And then when FooApplication (proprietary, free software, or otherwise) calls them, I want them to work. And for bonus points, it should be fast.

                      That's what I expect.
                      There's a good reason why many of those functions are missing. For instance, moern hardware no longer supports color tables - should drivers implement a slow software fallback for that case? What about hardware- and vendor-specific extensions?

                      What the goal should be is to make everything in OpenGL core available first, work on the compatibility profile second and, if there's nothing better left to do, add oddball extensions last. OpenGL 4.1 core is probably missing fewer than 100 entry points at this point (most of which are overloads of each other).

                      Edit: for comparison, OpenGL 4.1 compatibility has ~1000 entry points or ~2200 incl. extensions.

                      Comment

                      Working...
                      X