Announcement

Collapse
No announcement yet.

Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

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

  • #71
    Originally posted by allquixotic View Post
    Most significant changes the ATI guys make to their open source driver have to go through legal red tape. This red tape takes many times longer than actually writing the code, from what I hear. It's possible they have many fixes queued up but are waiting for them to be cleared.
    Huh ?

    The IP review is about making sure we don't accidentally expose too many "gory details of the chip design" along with the programming info. The focus is on the hardware info itself - registers & bitfields, PM4 packets, data structures, microcode binaries - and the rest of the code is untouched except for the HW info it contains. Once the initial release of programming info goes through IP review and gets released subsequent driver changes are made directly in the public repo without further review, *except* in the cases where additional programming info needs to be exposed.

    The reasons there have been no commits since the initial release are simple :

    - we haven't found a fix for the corruption & hangs yet, although we have confirmed that running fglrx first does address them, so Alex is working through the registers to find out which ones make the difference

    - the problems do not appear on Richard's systems, either at home or at the office, so it's hard for him to "fix them"

    - the other devs are focusing on getting r600g closer to production readiness rather than jumping on the Evergreen code... this may be a problem for the 7.9 release

    Nothing to do with IP review. There are no "queued up fixes".

    Originally posted by allquixotic View Post
    I think the system is broken, TBH. ATI thinks their own 3d driver algorithms are "intellectual property". They're mathematics for crying out loud. This is another instantiation of the Bilski debate, right here in our driver.
    Nothing to do with algorithms. I don't know whose system you are describing but it's not ours.

    Originally posted by allquixotic View Post
    And if you disagree with the above sentiment, then I expect that the asymptotic performance of Mesa3D on Radeon hardware will approach the performance of fglrx within 2% or so in the long run (or hey, even exceed fglrx performance, since you don't have to go through an abstract kernel interface like the one fglrx has). I'll be waiting for you to show me when relative performance parity has been reached - on any radeon hardware. Any at all.

    Of course it makes sense to keep the gory details of the chip design secret, but I think the discrepancy between the closed and open source driver performance is not about that, but rather about software algorithms. Again, Bilski.
    The performance difference between the open and closed drivers is a simple function of available developers -- the Catalyst driver shares a lot of code across multiple OSes and as a result enjoys maybe 50x the number of developers.

    The "60% to 70% of fglrx" performance estimate was based on the tiny size of the open source driver development community relative to proprietary driver teams, not the amount and nature of programming information we release. Proprietary driver teams share code across 100% of the client PC market (ie all OSes) and are staffed accordingly, while the open source driver teams are essentially staffed to the size of the Linux client PC market.

    Algorithms only go so far... at some point you just need great honkin' piles of hardware-specific code in order to get the most performance out of a piece of hardware, and the size of the development team *does* make a difference.

    Comment


    • #72
      Originally posted by bridgman View Post
      - the problems do not appear on Richard's systems, either at home or at the office, so it's hard for him to "fix them"
      Could you help his effort by giving him a system for which it currently is broken?

      Comment


      • #73
        Sure, if we could find one. First impression was that the problems were being seen with HD58xx but not with lower end hardware, but that turned out not to be the case. There were indications that the problems seemed to be Northbridge-related but that theory isn't holding up either.

        Right now Alex has one machine that shows the problems and that's it.

        Comment


        • #74
          Normally we rely on user and developer feedback to help determine hardware dependencies for problems, but we aren't seeing much feedback yet. I suspect that when the first user published that they had problems other users simply didn't try the code, which meant that we didn't get as many of the "it works on my system" and "it doesn't work on my system" reports which help to track down problems. We did get the feedback about running fglrx first, which is a big help.

          The community developers would normally have been testing the code by now but most of them are working on r600g instead.

          Comment


          • #75
            Originally posted by bridgman View Post
            ...Insightful comments...
            Sorry, sounds like I was a bit off my rocker this in the day

            I was under the (perhaps incorrect) impression of the following: once a driver is rendering correctly and seems to nominally support the features it's supposed to, making it work fast is basically an effort that is left to non-ATI developers. If they can reverse engineer fglrx to figure out how to get the last performance out of it, great. If they can come up with the code themselves, great. But because fglrx itself has techniques that ATI isn't comfortable with exposing to potential competitors, they leave these last optimizations out, allowing the driver's ultimate performance level (long term) to be decided by external contributors.

            Now if that's off base, then I'm sorry. If the ATI legal team would accept a commit from an ATI employee who is putting forth a "crown jewels" style commit that may contain ATI-patented software algorithms (which obviously would have some unique benefit for the features or performance of the driver), that's heartening. What you've claimed is that, if there were only time and manpower to get it done, the open source drivers could be made to be as fast as fglrx, and the legal review team would be fine with that? If I were hearing this from any other person, I would be reluctant to buy it; but coming from you, I accept it.

            How about a stronger, more abstract claim? Consider whether getting the most out of the hardware (in terms of performance and features) is compatible with the filtering imposed by the legal review process; i.e., the review process would not filter out potentially beneficial code just because it has some sort of proprietary value to ATI.

            If the two are indeed compatible, that is great. If not, we may reach a point where ATI's open source devs can not contribute further, even if they know what needs to be done. I would be more understanding if there were, in principle, a way to accomplish the same task without falling under the scope of your "IP", but what if -- hypothetically -- there were no other way? The hardware only functions a certain way, and maybe this is far-fetched, but perhaps there is only one best way to accomplish a certain task, or reach a certain level of performance. If that way is under some sort of trade secret or patent protection, I would wager that the legal team would hesitate, if not outright block the contribution, provided that the contribution is coming directly from an ATI employee. No? Then maybe I've misjudged the character of ATI as a for-profit corporate entity with an aggressive "intellectual property" protection policy.

            I regret that I've interpreted your policies as being bad for software freedom if in fact they are not, which is seeming the more likely alternative. I don't want the big wigs to conclude that those FOSS zealots are more trouble than they're worth, so I'll leave you be.

            Bah ... Now I feel like I'm just looking for a way to salvage my original argument by making some spin-off claim that may have more validity, but maybe I'm still wrong, so I'll quit while I'm ahead. I am so accustomed to corporate competitiveness screwing over open source projects that I've almost come to expect it. Sometimes people are just trying to get things done. I respect that.

            Comment


            • #76
              I don't think that the performance of fglrx is better because of secret code, or at least that "secret code" is not the major factor.

              The way I understand it, fglrx performs better because it has had about a thousand man-years of optimization invested in it, whereas the OSS driver has had maybe one man-year. If you invest a similar amount of time, you should approach similar performance, but it's tricky and annoying business.

              Also, the optimizations tend to make the code ugly and unreadable and difficult to maintain, so some optimisations will not be accepted in an open-source project anyway.

              Comment


              • #77
                Originally posted by bridgman View Post
                Normally we rely on user and developer feedback to help determine hardware dependencies for problems, but we aren't seeing much feedback yet.
                if you need something from the user community, you could have done the simple thing: ask.

                I've specifically asked if I should file proper bug reports about the things I'm seeing. I'm sure you've all read the question, yet I didn't even get a simple "yes, add all the information you can" or "we know about it already, but we have yet to determine why it happens or which systems are affected.". I sure would have spent more time trying to boil it down to a testcase (instead of playing guild wars) if I had known it would be useful.
                If you really needed testers, you could have asked Michael to add a small news item "AMD wants you to test the evergreen code!"; he gets the hits and you get the results.

                The official information said that you moved on to fusion, and it appeared you were just leaving the evergreen bugs behind to meet the "fusion OSS drivers on release" goal. As often, it took some ramblings of a misinformed user to get some reassuring statements from you - should we all learn from that?


                Now I know that posting on phoronix isn't part of your job description and that all of you are doing awesome work, given the difficulty of the subject and the understaffing. Still, I think a bit more communication could have made a difference here.
                Or are there any other (non-dev) communication channels I'm not aware of?

                Comment


                • #78
                  I was travelling for the last couple of weeks and wasn't able to keep up with all the forum traffic. When I'm back in town, get home from work, but can't get to sleep I sometimes have a chance to catch up and that's what you are seeing now.

                  We weren't stalled waiting for user feedback or anything, my comments were more related to "why don't you give Richard a system that fails ?" rather than "why aren't you making progress ?".

                  I don't remember any "official information" saying that we had moved on to Fusion (or hypothetical future discrete GPUs) and were not working on Evergreen. There are various rumours floating around but AFAIK none of them are true and I don't have time right now to hunt them all down and respond to them. Anything related to work on unreleased hardware is particularly difficult to respond to and I'm not even trying to go there right now.

                  Unless you hear otherwise, assume that everything is "business as usual", ie the developers are splitting time between a number of different activities, and that we will tend to shift to working on the next generation of hardware once we have basic working functionality on a previous generation so that we can gradually catch up with the rate of new product introduction.

                  Comment


                  • #79
                    It probably goes without saying that until we have the current GPU hangs & corruption resolved on Evergreen that work will remain a high priority...

                    ... but I'll say it anyways just for clarity

                    Comment


                    • #80
                      The "rumours" were straight from phoronix, sounded like he quoted you:
                      Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs
                      Additionally, John will be re-tasking AMD's open-source developers within a week or two. With the foundation of the Evergreen 2D/3D/video support now laid, AMD will leave the rest up to the open-source community to complete while John will take AMD's limited internal developers and begin working on their next-generation support.
                      But you have restored my faith, I'm sorry for wavering, and I'll repent by finishing that testcase I was working on

                      https://bugs.freedesktop.org/show_bug.cgi?id=29986

                      Comment

                      Working...
                      X