Announcement

Collapse
No announcement yet.

AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

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

  • #76
    Originally posted by pingufunkybeat View Post
    - The blob would not violate all kinds of licenses and be illegal to distribute for distributions, unlike Nvidia's legal minefield.
    Actually, there are some developers who argue that user-space binaries that rely on custom functionality from kernel modules are illegal. The text of the kernel GPL license only states that programs that use the normal system calls are not derivative works:

    The COPYING file shipped with the kernel begins with this text:

    NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
    Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.

    The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear.
    and

    Originally posted by Dave Airlie, the kernel graphics maintainer
    We are going to start to see a number of companies in the embedded space submitting 3D drivers for mobile devices to the kernel. I'd like to clarify my position once so they don't all come asking the same questions.

    If you aren't going to create an open userspace driver (either MIT or LGPL) then don't waste time submitting a kernel driver to me.
    This issue of whether it is legal to distribute a user-space driver that uses a kernel shim to provide custom "not normal" system calls hasn't gone to court yet, so we don't have a definite legal answer. Given that the Linux kernel has thousands of copyright holders, I wouldn't be surprised if an IP lawyer convinces one of them to test the legal field with this question at some point in the future.

    What AMD might do is to convert the existing open source driver to serve the dual purpose of providing system calls for both the open and closed user-space drivers. The question then is whether this is achievable without requiring custom system calls for the closed source driver. On the face of it, it might seem questionable - if they could have implemented the closed source user-space driver using only the existing kernel functionality in the first place, then why would they have bothered to write the closed kernel driver? But perhaps they had other reasons e.g. "protecting IP". Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.
    Last edited by chrisb; 03-22-2014, 08:53 PM.

    Comment


    • #77
      this is very interesting and I applaud AMD idea.

      My main worry is how many Linux developers would be working on this?

      I'm asking because with the pace of development of catalyst (about 3 bug fixes per month) it seems like the poor guy is alone and fix rougly less than 1 bug per week. If the idea discussed in this article requires major refactoring, that will take a very long time before seeing something.

      Concerning the explanations behind decision to have catalyst closed source:

      1. It contains over a million lines of code and it is too big hence it would not attract contributors anyway.

      I believe that it is not required to understand everything to a huge software project to be able to contribute to it. How many lines of code does the kernel have and does it stop it to get many new contributors to it?

      With good methods and tools, it is very easy to narrow down to very precise function where a problem is. Without the source I have been able to pinpoint problems 3-4 times inside catalyst. ie: XvPutImage for xserver v.15 support in 14.2. With the code source, I could have fixed the problem myself without having to wait for the sole AMD driver dev to fix and release the fix.

      2. Keep the sauce secret.

      It is AMD right and as a customer, I do not really care about using closed source software but only at one condition: The closed source software has to be top quality and bugs needs to be addressed quickly.

      If AMD is not able to provide that, they should let their customers do it themselves. I have installed 14.3 yesterday and here are the issues that I still have:

      opencl is not able to detect more than 1 cl device: The only reason that I had to stick with catalyst was good opencl 1.2 support. This one is gone now!
      I have a deadlock in fgrlx making X unkillable and using 100% CPU while playing a steam game. I have to reboot my machine and it did happen twice yesterday.
      This one is fixed in 14.3 but it was so bad that I need to mention: Impossible to play video without crashing X on the first frame displayed.

      As a professional software developer myself, this is too much problems for me. As I deal already fulltime with software problems, when I am at home, I just want a system that works well. Hence, still waiting a couple of months to see the situation improve is too much to ask. I'll keep my 7970s, install open source drivers, keep watching if AMD finally delivers but for my main machine, it will now be a high-end NVIDIA card to make my life easier.

      Sincere good luck with your ambitious project!

      Comment


      • #78
        I am not quite sure how they would do this:
        - Mantle on Linux? Sorry, resources are scarce, maybe we can later look at if it is even worth our time.
        - UVD for RS780/880/RV790? Sorry, resources are scarce, maybe later, maybe never.
        But:
        - Major changes in the driver to be able to use the radeon kernel module, which will take a significant amount of developer time? Hey, we totally can do that!

        WTF?

        Comment


        • #79
          Can somebody tell me how win, mac, and android are handling the situation with the closed source drivers and why is it such a pain in the ass to do the same thing for desktop Linux? Is it because of the outright hostile behavior of the kernel devs towards anything and everything closed source, or is it simply an engineering problem to which nvidia dedicates more engineering effort and amd very little?

          Comment


          • #80
            Originally posted by Vim_User View Post
            I am not quite sure how they would do this:
            - Mantle on Linux? Sorry, resources are scarce, maybe we can later look at if it is even worth our time.
            - UVD for RS780/880/RV790? Sorry, resources are scarce, maybe later, maybe never.
            But:
            - Major changes in the driver to be able to use the radeon kernel module, which will take a significant amount of developer time? Hey, we totally can do that!

            WTF?
            Well, the whole point here is that once done it would reduce the time they have to spend on their driver, since support would just already work in the kernel. So the idea is to do some work up front to save down the road.

            Comment


            • #81
              Originally posted by F i L View Post
              It's been a year or so since I've tried the open-source drivers really
              There's your problem; expect massive performance increases between then and now with the FOSS driver, especially with RadeonSI (which is used with your card).

              Comment


              • #82
                Originally posted by Anarchy View Post
                Can somebody tell me how win, mac, and android are handling the situation with the closed source drivers and why is it such a pain in the ass to do the same thing for desktop Linux? Is it because of the outright hostile behavior of the kernel devs towards anything and everything closed source, or is it simply an engineering problem to which nvidia dedicates more engineering effort and amd very little?
                You seem to be mixing a lot of different stuff up here, but i'll try to clarify a bit.

                1. Win and Mac are proprietary, which means that proprietary code can link into it with no problems. You could do the same with BSD code. You cannot with GPL, because it then becomes a "derived" code which is covered by the GPL as well, and the gpu driver developers don't want that. So to work around this, they create a little open source shim code which talks to the internal kernel API's and their proprietary driver, and claim that works around the whole issue.

                Some people have doubts about that, but no one really cares enough to sue, because most people want the drivers to stick around anyway.

                Just to be clear, this issue has nothing to do with the devs being "hostile" or "friendly". It's 100% about the legal requirements of the GPL and lawyers. Even if the devs said to go ahead and ignore the law, the lawyers at the GPU companies would ignore them because they don't want to be exposed to million dollar lawsuits from random people on the internet who download a linux distro and decide to sue them.

                2. Nvidia does spend more money on their linux drivers, there is no question about that. But they have the same issues. When new kernels come out, your nvidia driver won't work until they come out with a new version that's updated to work with it.

                3. The problem is compounded by the fact that the linux internal API isn't frozen, new versions are constantly coming out, and different distros all have their own patchsets. In Windows and Mac, that API can sometimes change, but it mostly stays the same over long periods of time and they have much fewer versions of the OS to support. In linux, every release usually breaks something. To help mitigate that, the open source shim the proprietary drivers ship with doesn't come pre-built. It's instead compiled and linked against your kernel when you install the driver, so that it can work with your specific version.

                4. The idea here is that AMD would get rid of their kernel side code entirely, and just use the same kernel API that the OSS drivers use. That would mean they could probably get rid of the shim as well, since they'd be using standard kernel api's rather than manually hooking in their own code. And it should just work by default in all the kernels out of the box, since it would be maintained as part of that kernel rather than being part of the AMD driver.

                5. Android is a completely separate beast. Most ARM devices just have completely custom drivers built directly for them - which is one of the reason official updates are so slow. There isn't generally a generic driver that they use, instead the manufacturer writes the driver specifically for each piece of hardware. Then any updates you get are carefully controlled - sent to you via the phone company, for example - and not just downloaded at will off the internet.
                Last edited by smitty3268; 03-23-2014, 03:16 AM.

                Comment


                • #83
                  Originally posted by chrisb View Post
                  This issue of whether it is legal to distribute a user-space driver that uses a kernel shim to provide custom "not normal" system calls hasn't gone to court yet, so we don't have a definite legal answer. Given that the Linux kernel has thousands of copyright holders, I wouldn't be surprised if an IP lawyer convinces one of them to test the legal field with this question at some point in the future.

                  What AMD might do is to convert the existing open source driver to serve the dual purpose of providing system calls for both the open and closed user-space drivers. The question then is whether this is achievable without requiring custom system calls for the closed source driver. On the face of it, it might seem questionable - if they could have implemented the closed source user-space driver using only the existing kernel functionality in the first place, then why would they have bothered to write the closed kernel driver? But perhaps they had other reasons e.g. "protecting IP". Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.
                  That's the whole idea, to use the radeon kernel driver instead of the catalyst one. It's not a shim and is actually needed for radeon.
                  As for why they bothered to write the closed kernel driver: I'm pretty sure that at that point, the radeon kernel driver did not exist.

                  Comment


                  • #84
                    Michael didn't mention it by name, but HDCP would be another thing that would not be supported. It would need to be in kernel, but doing so would obviously reveal things, or require a blob extension that cannot have its interfaces upstreamed.

                    Comment


                    • #85
                      what kernel developers think about this?

                      Comment


                      • #86
                        Originally posted by chrisb View Post
                        if they could have implemented the closed source user-space driver using only the existing kernel functionality in the first place, then why would they have bothered to write the closed kernel driver?
                        Because there was no (good) open-source kernel driver available when fglrx was born. Today the open-source kernel driver is almost as advanced as the closed-source one.

                        Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.
                        When they have to add missing functionality to the open-source kernel driver they could always add that stuff to the gallium driver, too, so it would be a win-win.

                        Comment


                        • #87
                          Originally posted by curaga View Post
                          Michael didn't mention it by name, but HDCP would be another thing that would not be supported. It would need to be in kernel, but doing so would obviously reveal things, or require a blob extension that cannot have its interfaces upstreamed.
                          That's what I was talking about. Who cares about graphics card HDCP, when there are no players capable of HDCP?

                          Comment


                          • #88
                            Originally posted by rudregues View Post
                            What about Intel? AFAIK Intel graphics driver is totally open. Does Intel has any disadvantages right now because of this?
                            yes they have: both nvidia and amd are violating some patents in their secret souce that they do not want to be seen. and intel has to skip some nice stuff patented by others because they are all open source.

                            p.s. just my guess, but i would bet a lot of money on this.

                            Comment


                            • #89
                              Originally posted by curaga View Post
                              Michael didn't mention it by name, but HDCP would be another thing that would not be supported.

                              HDCP is evil. The less support there is for such atrocities, the better.

                              Comment


                              • #90
                                Originally posted by smitty3268 View Post
                                Well, the whole point here is that once done it would reduce the time they have to spend on their driver, since support would just already work in the kernel. So the idea is to do some work up front to save down the road.
                                I don't get that. They still would have to collaborate with the radeon developers to get release-day support for new hardware, tehey still have to get all the features work that aren't currently supported with radeon, so where exactly would they reduce the time? This sounds like: Hey, we offload all this work to the FOSS developers which will reduce the work we have to do and as a nice side effect they can't blame us when new hardware doesn't work, we just say "Here is the documentation, why don't you just implement it?"
                                Sorry, but AMD has a nice track record of screwing their customers and to me this sounds awfully like another attempt.

                                Comment

                                Working...
                                X