Announcement

Collapse
No announcement yet.

ATI R600 Gallium3D Driver Continues Advancing

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

  • #31
    Originally posted by monraaf View Post
    I don't think Ubuntu 10.10 will have Evergreen acceleration by default. They do have a recent mesa 7.9 git snapshot, but are missing the drm lockup patches and the required ddx version.
    They would probably best be advised to ship it in a package labeled "experimental", like Fedora 12 did previously for early 600/700 3D.... mesa-dri-drivers-experimental. Generally, forcing a user to manually install a package labelled like this to enable 3D support makes it pretty clear that it is there, but buggy.

    ... And another one named gallium-superexperimental-caution

    Comment


    • #32
      Originally posted by bridgman View Post
      The Gallium3D paths are not "inherently faster" or anything (in fact you could argue that all other things being equal they are just the tiniest bit slower), but the real advantage is a cleaner internal design that allows the devs to work more productively.
      a cleaner design and more dev productivity os much more than a tiniest bit faster...

      thats because the OS-Radeon driver lag on manpower and no linux user want an second fglrx code mess...

      Comment


      • #33
        Yes, but the point I'm trying to make is that any performance advantages of 600g will appear over time as a consequence of the code being a "nicer place to work", rather than appearing immediately as a consequence of "being Gallium".

        Comment


        • #34
          Originally posted by bridgman View Post
          rather than appearing immediately as a consequence of "being Gallium".
          OMG

          [stupid 10 characters limit]
          ## VGA ##
          AMD: X1950XTX, HD3870, HD5870
          Intel: GMA45, HD3000 (Core i5 2500K)

          Comment


          • #35
            Full steam ahead.

            http://cgit.freedesktop.org/mesa/mes...t=grep&q=r600g

            Comment


            • #36
              Originally posted by bridgman View Post
              Yes, but the point I'm trying to make is that any performance advantages of 600g will appear over time as a consequence of the code being a "nicer place to work", rather than appearing immediately as a consequence of "being Gallium".
              if you watch this: http://cgit.freedesktop.org/mesa/mes...t=grep&q=r600g

              codewaver dev's, vmware dev's, community dev's more and more non amd dev's

              i'm sure Galium3D will be much faster than the classic one.. because more devs bring more speed.

              Comment


              • #37
                Originally posted by Qaridarium View Post
                because more devs bring more speed.
                Or more bugs....

                Comment


                • #38
                  Originally posted by droidhacker View Post
                  Or more bugs....
                  So said the embodiment of optimism...

                  Comment


                  • #39
                    Strictly speaking, more devs will bring more code *and* more bugs, but since most new devs learn the driver code by *fixing* bugs it should all work out

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      Strictly speaking, more devs will bring more code *and* more bugs, but since most new devs learn the driver code by *fixing* bugs it should all work out
                      professional high skilled Studys show that opensource projects like the linux kernel or apache webserver do have the lowest rate of errors per 1000 lines of code only 0,3 errors.

                      cloused source products do have much more errors per 1000 line of code.

                      be sure the FGLRX do have much more errors per 1000 line of code than the linux kernel.

                      Comment


                      • #41
                        I think that there are two things to think about regarding bugs;

                        1) at a constant rate of errors per lines of code, doubling the code means doubling the bugs.
                        2) as the complexity increases, the rate of bugs tends to rise as well since it becomes exponentially more difficult to analyse the code in the "big picture".... especially when bad development methodologies are used, as is likely more common in closed source code.

                        Comment


                        • #42
                          It's a pretty safe bet that proprietary driver development is using more advanced processes than open source these days. I think you'll find that the defect density ((latent + known defects) / LOC) is actually lower for closed source drivers than for open source drivers. I can't go into a lot of details but you might be surprised how far proprietary driver development has come in the last decade.

                          I agree with the exponential rise in complexity as the driver grows though... that is a problem for open and closed drivers. The open source stack for ATI radeon GPUs has gone from ~50 KSLOC to over 250 KSLOC in the last couple of years (not counting close to 1,000 KSLOC of common Mesa code) and there is probably still some growing to do. By way of comparison, the proprietary drivers are well over 10,000 KSLOC.

                          That said, the main challenges with closed source Linux drivers are more related to "big expectations vs. small market share/resources" and "large code size due to code sharing across multiple OSes" than to development process.

                          Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).

                          I think this post added 5 or 6 to my post count... maybe 7 now.

                          Comment


                          • #43
                            Actually, OSS has another advantage

                            Originally posted by bridgman View Post
                            Open source has one big advantage over closed source development, however, which is that users can bisect regression failures.
                            With OSS, you don't get exchanges like this:
                            User: Hi, The fglrx driver is having trouble running on my laptop.
                            AMD: Did you buy a discrete graphics card from us?
                            User: No, it's a laptop with an integrated AMD graphics chip.
                            AMD: Then go talk to your laptop vendor instead. Goodbye.

                            Comment


                            • #44
                              Originally posted by bridgman View Post
                              Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world
                              This implies answering to your users. As soon as amd released the specs I bought an ati card and I started to use it with fglrx discovering some issues with libdrm v.<something>. I contacted the debian maintainer and he told me he was unable to do anything, so I contacted ati's technical support (linking the bugs reports) and I received no answer. I don't think they wanted some kind of user interaction and in fact I reported fglrx issues no more.
                              ## VGA ##
                              AMD: X1950XTX, HD3870, HD5870
                              Intel: GMA45, HD3000 (Core i5 2500K)

                              Comment


                              • #45
                                Originally posted by bridgman View Post
                                Open source has one big advantage over closed source development, however, which is that users can bisect regression failures. We really need to get something similar implemented in the closed source world (the problem is sanitizing out future product info, not tools/process).
                                Something like walking a customer through a bisect session with a script on a web server?

                                You'd probably need a server with a huge repository of binary patches corresponding to commits, and with every bisect step merge the necessary patches to a single one for download, so the customer can easily apply and test.

                                I guess that would be a real win for your customers.

                                Comment

                                Working...
                                X