Announcement

Collapse
No announcement yet.

AMD Ports Open-Source Linux Driver To Windows Embedded

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

  • #51
    Originally posted by Thatguy View Post
    No I am specifically referring to the quality and speed with which the current gallium3d stack compiles code for the card "gpu" itself. Its factors slower then your closed source driver, a situation that really isn't good at all.
    I don't think this is even true. There's definitely a lot less optimization happening in the open source shader compiler for 6xx and higher than in the proprietary shader compiler (the proprietary shader compiler alone is ~4x the size of the entire open source driver stack), but code quality from the open source shader compiler for 3xx-5xx seems to already be in the same ballpark as the one in the last proprietary driver, and the 6xx+ code is probably generating code that runs 1/2 - 2/3 as fast as shader code generated by the proprietary driver already.

    Originally posted by Thatguy View Post
    It really begs to ask the point, why bother with a open source driver if the performance is fractional that of the closed source driver.
    I don't get this question. The first thing people want from an open source driver is being open source. Priorities after that are being maintainable, being easy to integrate into Linux distributions, and being useful for out-of-box distro applications. Distros want to provide a great out-of-box experience for their users, and open source drivers make that a lot easier.

    The performance of the open source driver on general desktop usage and applications is already better than the proprietary driver in many cases - what is missing is the 3D performance optimizations for complex games and for workstation apps. I expect you will see continued improvement in this area but AFAIK matching the code-shared proprietary driver 3D performance is not a real priority for any of the developers. Functionality & features with decent performance is a priority; proprietary equivalent performance not so much.

    Originally posted by Thatguy View Post
    Will AMD invest the time, money and resources into making the gallium3d arch run worth a shit???
    I believe most people would say that it already does. If your question is "will AMD invest the time, money and resources into making the gallium3d-based GL drivers match fglrx performance ?" I think the answer is no. For most other interpretations of your question, I think the answer is yes.
    Last edited by bridgman; 29 October 2011, 11:02 AM.
    Test signature

    Comment


    • #52
      [QUOTE=bridgman;235885]I don't think this is even true. There's definitely a lot less optimization happening in the open source shader compiler for 6xx and higher than in the proprietary shader compiler (the proprietary shader compiler alone is ~4x the size of the entire open source driver stack), but code quality from the open source shader compiler for 3xx-5xx seems to already be in the same ballpark as the one in the last proprietary driver, and the 6xx+ code is probably generating code that runs 1/2 - 2/3 as fast as shader code generated by the proprietary driver already. [QUOTE]

      Well thats what I am asking, can those same type of code optimiziation routines be put into the opensource driver stack so we can all benefit from them ? I mean jesus once its out in the open the community might be able to help take it allot further !!running at 1/2 the speed ? where ? Everybenchmark I see shows FRACTIONAL performance IE 1/8 1/16 of the performance of the closed driver. This situation is rediculous to. You want to embrace the open source community, don't do it at arms length. Theres nothing in your code or hardware Intel/Nvidia aren't already reverse engineering anyways.


      I don't get this question. The first thing people want from an open source driver is being open source. Priorities after that are being maintainable, being easy to integrate into Linux distributions, and being useful for out-of-box distro applications. Distros want to provide a great out-of-box experience for their users, and open source drivers make that a lot easier.
      Yeah thats great, help just enough to make it work halfassed. Look at this as a opputunity to really get behind the opensource revolution, here you have a group of people willing to help. Speaking of which a few other OS project would really like some help. send me a PM if your curious.


      The performance of the open source driver on general desktop usage and applications is already better than the proprietary driver in many cases - what is missing is the 3D performance optimizations for complex games and for workstation apps. I expect you will see continued improvement in this area but AFAIK matching the code-shared proprietary driver 3D performance is not a real priority for any of the developers. Functionality & features with decent performance is a priority; proprietary equivalent performance not so much.
      Performance parity is what should be the expectation, I don't buy a superpowerful GPU so I can only use 50% of its capability at best.


      I believe most people would say that it already does. If your question is "will AMD invest the time, money and resources into making the gallium3d-based GL drivers match fglrx performance ?" I think the answer is no. For most other interpretations of your question, I think the answer is yes.

      the answer is no, becuase none of the mainline code for the propritary driver has made it downstream for things like shader optimization. why not do this the right way, yank out the MS bits and just give the source to the community, let them develope your driver for linux ? The answer seems stratlingly obvious.

      Common man, go all in.

      Comment


      • #53
        Originally posted by Thatguy View Post
        Well thats what I am asking, can those same type of code optimiziation routines be put into the opensource driver stack so we can all benefit from them ? I mean jesus once its out in the open the community might be able to help take it allot further !!running at 1/2 the speed ? where ? Everybenchmark I see shows FRACTIONAL performance IE 1/8 1/16 of the performance of the closed driver.
        OK, I see the disconnect. You're asking questions based on the assumption that the shader compiler (which produces the GPU code) is responsible for most of the performance difference between proprietary and open source drivers. As far as we know that is not the case, although there are probably some specific apps where it makes more of a difference.

        Most of the performance differences are related to code all across the driver stack. The open and closed drivers have completely different internal architectures (proprietary drivers code share across multiple OSes, open source drivers code share across multiple HW vendors) so you can't just "port over the optimizations". The proprietary driver is ~100 times the size of the open source driver and needs a proportionally larger team to maintain it. Optimizations tend to be *big*, because they are all about adding specialized code for specialized scenarios and that quickly takes you to 20x or 50x the code size.

        Since the open and proprietary driver architectures are different we would be talking about essentially an all new open source driver 50 or 100x the size of the current one, requiring 50-100x the developers to maintain it. Are you asking us to invest 50-100x the resources in Linux that we do today, noting that would be far more than we would make from the Linux market even if we had 100% market share ?

        It's reasonable to ask, but I don't think any reasonable company would say "yes".
        Test signature

        Comment


        • #54
          Originally posted by bridgman View Post
          OK, I see the disconnect. You're asking questions based on the assumption that the shader compiler (which produces the GPU code) is responsible for most of the performance difference between proprietary and open source drivers. As far as we know that is not the case, although there are probably some specific apps where it makes more of a difference.

          Most of the performance differences are related to code all across the driver stack. The open and closed drivers have completely different internal architectures (proprietary drivers code share across multiple OSes, open source drivers code share across multiple HW vendors) so you can't just "port over the optimizations". The proprietary driver is ~100 times the size of the open source driver and needs a proportionally larger team to maintain it. Optimizations tend to be *big*, because they are all about adding specialized code for specialized scenarios and that quickly takes you to 20x or 50x the code size.

          Since the open and proprietary driver architectures are different we would be talking about essentially an all new open source driver 50 or 100x the size of the current one, requiring 50-100x the developers to maintain it. Are you asking us to invest 50-100x the resources in Linux that we do today, noting that would be far more than we would make from the Linux market even if we had 100% market share ?

          It's reasonable to ask, but I don't think any reasonable company would say "yes".
          No, I personally think investing any resources into "linux" for a graphics design is a waste of time and money. To much API/ABI breakage, to many subsystem changes just to many problems.

          I am asking AMD to open source the entire internal driver and let everyone who wants to support it do so on whatever project they are working on.Just let us in. We can likely find a way to leverage your code. Hell many open source groups would GLADLY use your windows driver if they had the first clue how to talk to it properly !! I'd settle for a binary x86 blob with a open api document to state how to communicate and support the blob.

          Point is, your making this harder then it has to be by going down the street by making 3 lefts and then 3 rights and then 3 lefts and then 3 rights. Travel in a straight line.

          Comment


          • #55
            Originally posted by Thatguy View Post
            I am asking AMD to open source the entire internal driver and let everyone who wants to support it do so on whatever project they are working on.Just let us in.
            Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes, and opening up the source code for the proprietary driver would put those DRM implementations at risk. We went through a couple of exercises trying to sanitize proprietary driver code enough to safely release it, but they didn't work and in the end we gave up. I don't think this is a workable option.

            Your suggestion about wrapping the binary driver with editable code is more in line with what we are thinking -- the driver already ships with a kernel compatibility layer in source code -- and I think doing more of that has a greater chance of success.
            Test signature

            Comment


            • #56
              Originally posted by bridgman View Post
              Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes, and opening up the source code for the proprietary driver would put those DRM implementations at risk. We went through a couple of exercises trying to sanitize proprietary driver code enough to safely release it, but they didn't work and in the end we gave up. I don't think this is a workable option.

              Your suggestion about wrapping the binary driver with editable code is more in line with what we are thinking -- the driver already ships with a kernel compatibility layer in source code -- and I think doing more of that has a greater chance of success.
              I and many other people in the OSS community likely wouldn't care how we get a 3d accelerated driver. In fact IMHO a wrapped makes a ton of sense if you have good internal API/ABI stability. I realize there is tons of drm code, I assume this is mostly for UVD ? If so OSS can implement uvd in shader language. Plenty of knowledge out there to do this.

              Can you ask your superiors about maybe working with opensource groups about wrapping the driver ? It would make more sense and from a maintenance standpoint would sure be much easier for many small OS groups to keep it working.

              Sorry for busting your balls so much. Just trying to get you guys to think about other ways the OSS community can get 3d accel.

              Send me a pm. I know a few guys dying to put 3d driver in a OSS and they aren't always opposed to writing wrappers to do so.

              Comment


              • #57
                Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes,
                I would argue that, if the DRM can be broken via the source release sans key, then it is not "robust". Your obligation is to protect the PK that was licensed to ATI by the MPEG-LA and or DCP LLC. It's akin to saying that Apache cannot release their mod_ssl source because it may compromise the PKs of their customers' implementations.

                I'm not really looking to debate this, There's really nothing to debate. I'm just pointing out that the entire rationale for withholding (any) source code is built on a mountain of bullcrap.

                Last note: It also hinders the development of better, "more robust" competing DRM standards. That's what the DCP LLC is really trying to prevent.
                Last edited by russofris; 31 October 2011, 11:46 AM.

                Comment


                • #58
                  Originally posted by bridgman View Post
                  Ahh, OK. We discussed that a lot back in 2007/08. The proprietary drivers have to implement robust DRM for other OSes, and opening up the source code for the proprietary driver would put those DRM implementations at risk. We went through a couple of exercises trying to sanitize proprietary driver code enough to safely release it, but they didn't work and in the end we gave up. I don't think this is a workable option.

                  Your suggestion about wrapping the binary driver with editable code is more in line with what we are thinking -- the driver already ships with a kernel compatibility layer in source code -- and I think doing more of that has a greater chance of success.
                  With your AMD hat on I know you can't reply to this.

                  By robust DRM, you actually mean that it fails to protect one single Blu Ray disc (as evidenced by all the Blu Ray pirate rips), and all it actually manages to do is maliciously disrupt open source software and be a pain in the ass to people who actually bought a disc that won't play.

                  Comment


                  • #59
                    Originally posted by russofris View Post
                    Your obligation is to protect the PK that was licensed to ATI by the MPEG-LA and or DCP LLC.
                    Nope, not even close. Our obligation is to robustly implement specific technical measures which help others to protect the keys they were issued.

                    Originally posted by russofris View Post
                    I'm not really looking to debate this, There's really nothing to debate.
                    Test signature

                    Comment


                    • #60
                      Originally posted by Qaridarium
                      a shader based acceleration is better because its more flexible this means WebM support is easy by shaders.

                      all the FUD around the UVD unit is just a joke its a crap technique with bullshit.

                      open up the UVD crap? it makes no sense for opensource users because UVD1-3 can not handle any opensource video format.
                      You're incorrect. There are plenty of open source codecs that implement patent-encumbered media formats.

                      You mean to say they only chose to support MPEG Patent Troll Authority formats when they could have used unencumbered ones instead or in addition to.

                      Comment

                      Working...
                      X