Announcement

Collapse
No announcement yet.

AMD's Open-Source Strategy Explained

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

  • AMD's Open-Source Strategy Explained

    Phoronix: AMD's New Open-Source Strategy Explained

    Rumors and speculations have been flying around for months about ATI/AMD opening up the source-code to their Linux display driver or providing their GPU specifications to community developers. This for the most part had started after Henri Richard's statement at the Red Hat Summit earlier this year. Well, those rumors can finally be put to rest. AMD will be providing NDA specifications, an open-source library, and there is a new open-source graphics driver as a result. AMD will continue producing a closed-source proprietary driver; however, they are opening the source-code to a critical library with accompanying GPU specifications for X.Org developers. To get the ball rolling, AMD is also funding the development of a new open-source R500/600 driver.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    And here I thought it was cold two days ago... >:-)

    Comment


    • #3
      AMD will be providing NDA specifications, an open-source library, and there is a new open-source graphics driver as a result.
      I'm...confused. What's the point of having NDAs if the driver's going to be open? It can't be that hard to figure out what's doing what..

      The aim of this open-source driver is not to overtake the fglrx driver but rather is designed for those who just want a working desktop with 3D capabilities and basic video playback.
      Maybe that's what the NDA is for? To make sure the open driver doesn't surpass the proprietary one?

      Edit: just to clarify the last question: because the specs are NDA'd, the open source community can't implement new features on their own, thus the proprietary driver remains in the lead.

      Does anyone have any thoughts on this?
      Last edited by Xipeos; 06 September 2007, 01:04 PM.

      Comment


      • #4
        i think this NDA is very very very evil thing.

        imagine for a second
        - all current avivo/radeon xorg developers get involved.
        - they implement all documented functionality
        - some of them feel like catching up to fglrx is the way to go (because fglrx will have some extra features that won't be in the specs).
        - ati/amd cancels the nda because they attempted reverse engineering on fglrx (remember bitkeeper and linux?)
        - finally, they cannot develop opensource driver because of being tainted with NDA (like airlied was).

        call me paranoid, but that's the danger i can see there. it happened once to airlied, and it might happen again.

        btw what does "basic video playback" mean. unaccelerated?

        Comment


        • #5
          Digg: http://digg.com/linux_unix/ATI_AMD_s...tegy_Explained
          Michael Larabel
          https://www.michaellarabel.com/

          Comment


          • #6
            I wonder how many people will receive specs under the NDA. I would prefer that AMD release their specs openly, because releasing under the NDA really hobbles development. For example, I'm interested in driver development but have no expertise and in fact only limited programming experience. I'd never be able to qualify for information under an NDA, but I feel like if I had the information, I might be able to make some minor contributions.

            I'm also concerned that AMD insists that the open-source driver will have only "basic" functionality. Does this mean that they will not release all of the specs even to those who sign an NDA, or simply that they're beefing up internal driver development and don't expect open-source developers to be able to match that? Will those who sign up for example, be able to get specs for accelerated video decoding if they want to implement it, or will AMD not provide that information at all?

            Overall, I'm glad that AMD is finally showing some commitment to getting their hardware well-supported in linux, but I'm concerned that they will hobble the open-source driver in order to keep fglrx ahead.

            Comment


            • #7
              Despite what it says in the article aobut AMD's Open Source strategy explanation, this looks like R200 all over again. Don't get me wrong, I think it is a very good thing what they are doing, and it could be very beneficial even for non Linux and even Windows platforms (especially the library for talking to the BIOS)... However, this also means that the NDAs most likely apply to those parts of the hardware that either implement third party IP, or the like... So long as the open source drivers don't lag behind as dramatically as the "radeon" driver did for R200 comopared to the "fglrx", I'm OK. After all, it is not AMD's call to open those parts (though I'd like them to disclose those parts too, like the MPEG engine and texture compression (S3TC et al), Z compression algorithms, etc), but since those are licensed from third parties... never gonna happen, unless VIA opens up S3TC and the others open up their specs, it is NOT gonna happen.

              It sucks that just like "dependency" hell, we are being held back due to these other dependencies.

              Comment


              • #8
                Originally posted by TechMage89 View Post
                I wonder how many people will receive specs under the NDA. I would prefer that AMD release their specs openly, because releasing under the NDA really hobbles development. For example, I'm interested in driver development but have no expertise and in fact only limited programming experience. I'd never be able to qualify for information under an NDA, but I feel like if I had the information, I might be able to make some minor contributions.

                I'm also concerned that AMD insists that the open-source driver will have only "basic" functionality. Does this mean that they will not release all of the specs even to those who sign an NDA, or simply that they're beefing up internal driver development and don't expect open-source developers to be able to match that? Will those who sign up for example, be able to get specs for accelerated video decoding if they want to implement it, or will AMD not provide that information at all?

                Overall, I'm glad that AMD is finally showing some commitment to getting their hardware well-supported in linux, but I'm concerned that they will hobble the open-source driver in order to keep fglrx ahead.
                Access to specifications isn't needed at all to do minor or even big contributions, it might help but it's not magic things. Wasn't all R300 & avivo & other things done without specifications ? Of course i would prefer freely dl specifications but you can't make this happen in just one step i am pretty (maybe i am bit too optimistic on that ) sure we will see this again in the future.

                On the functionality points i think i made, and others too, my self clear to AMD that we want somethings allmost full functional for instance 90% of functionality. I am realistic here because there is things they can't tell us (HDCP, macrovision, ...) and this things are often tightly linked with others functionality so they can't provide all of this, and NDA is likely their for that so we can see how it works but just don't make code for using HDCP or compromissing the whole crypted things while still using others functionality.

                To sum up, their word: we want a good open source driver and if in the end it outperform the closed source driver than we will clap but we would prefer to be better. So it's a competition but as a developer i am not willing to put little dirty trick to make one app go 5pfs faster and another little hack for another app to win again 3fps. I want a reliable, performant and clean (code) driver.

                So the show will begin soon

                Comment


                • #9
                  It would be nice if openning up the hardware would result in openning up programming possibilities.

                  those video cards have very impressive performance under certain workloads. It would be nice to harness that sort of thing for things like 3D rendering (thinking of Povray and such), media encoding, encryption, or whatever else people can think of.

                  Essentially these GPUs things are like CPUs, aren't they? To me this is something that simply cannot be done nearly as well under Windows due to the static closed-source nature of the OS. It could give Linux quite a advantage and make inroads into more of the low-end/mid-range 3D graphics and movie/tv arena. It could provide very cost-effective performance.

                  Also hopefully this would put more steam behind things like having the LLVM framework support GPUs for graphics programming. This could probably help out Linux desktop quite a bit...
                  I've been toying for a while with the idea of rewriting programmable pipeline in Mesa. The most obvious reason is the fact that fragment sha...
                  Last edited by drag; 07 September 2007, 04:16 AM.

                  Comment


                  • #10
                    check this (it's from lwn.net, but for these articles, you have to pay):

                    it seems that it is just because the fusion gpu/cpu

                    Comment

                    Working...
                    X