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

  • #61
    (and really, reopening bugs on different issues is a bad habit)

    Comment


    • #62
      Originally posted by bridgman View Post
      OK, that seems like a useful clue. Do you still get hangs eventually when running the open drivers after fglrx ?
      No, for as far as I have tested it I haven't seen any hangs after that.

      Which GPU are you using ?
      This is on a HD 5750.

      Comment


      • #63
        Does anyone know what the plan is (if there is one!) for continued development on this? I just checked the evergreen_accel branch and it appears there hasn't been a commit for 9 days.

        In face of the (seemingly unexpected) corruption and crashes, is it still the case that the AMD guys are being moved off Evergreen and onto HD6000?

        Comment


        • #64
          Originally posted by Wingfeather View Post
          Does anyone know what the plan is (if there is one!) for continued development on this? I just checked the evergreen_accel branch and it appears there hasn't been a commit for 9 days.

          In face of the (seemingly unexpected) corruption and crashes, is it still the case that the AMD guys are being moved off Evergreen and onto HD6000?
          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.

          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.

          I would rather that ATI go ahead and commit un-obfuscated drivers that contain the most maintainable and efficient algorithms they are aware of to provide the required functionality, with no regard to how much information about the hardware it potentially exposes. It might save Nvidia a week or two on figuring out what ATI is doing, but I have no doubt that if Nvidia really feels that ATI has techniques they lack, they've already taken apart a dozen or more HD5870s in their office, and run a $10,000/license disassembler on the Windows driver.

          It's the kind of double-tongued scenario that we have with most corporate-controlled "openness". They play the openness for the PR and approval of their customers, but it's really a sham, because they intentionally censor and filter everything before they "open" it up. In this case, it's not about the public being withheld information, but rather, correct, efficient, and timely drivers.

          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.

          Just think: if there were no clever algorithms arms race between Nvidia and ATI, they would actually have to compete on more difficult terrain, like customer service, timeliness and license of drivers, price, and hardware bells and whistles. They would still be motivated to develop innovative algorithms (or at least use the ones others have developed), because as soon as they let their guard down, their cards would immediately get outperformed by the competition, and they'd have to find a way to make up for it. And they could still use timing as a way to gain a "landslide" market share over the competition: make a whole bunch of new cards, push out a great new driver with innovations, customers realize the superior solution and buy it... by the time your competitor has figured out what you've done to beat them, then make a release of it, you've already made your sales.

          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.

          Bring down the iron curtain and give us true openness; cut out the red tape.

          Comment


          • #65
            Well that reply went awfully off-track.

            Comment


            • #66
              Originally posted by etnlWings View Post
              Well that reply went awfully off-track.
              Did it? I provided some background on why there haven't been any commits for 9 days, and why it may be a while until we see any more coming from ATI.

              To put it apolitically, then, how about this: yes it is being worked on, but you'll have to wait n more days for the code to clear ATI legal before it's released. They'll eventually get it to a point where it's rendering correctly but you've just got to wait.

              How's that?

              Comment


              • #67
                There's no evergreen accel code waiting for red tape right now. In addition to fixing issues on older asics, I've been tracking down the GPU hangs in the evergreen code. It's a complex, time-consuming process.

                Comment


                • #68
                  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.
                  Test signature

                  Comment


                  • #69
                    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


                    • #70
                      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.
                      Test signature

                      Comment

                      Working...
                      X