Announcement

Collapse
No announcement yet.

NVIDIA Developer Talks Openly About Linux Support

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

  • #46
    Originally posted by mtippett View Post
    Can you expand on your view on simplification?

    From my discussion with the X devs pushing KMS, it solves a number of problems
    o Flicker on boot (desktop experience - RH is investing here)
    o BSOD like behaviour (don't laugh, it's coming with KMS)
    o Removes the other kernel drivers from the picture (directfb, vesafb/radeonfb, etc). The X devs are open to former kernel fb devs joining them, but don't really care to directly include their interfaces.
    o Some say reliable suspend/resume (see my upcoming response for that).
    with KMS the X.org code doesn't need to know how to configure every possible video card in existance. Instead it uses a standard interface to ask the kernel to configure things for it. The kernel already needs to know how to do this to support other things like fb, and text consoles. With KMS X.org does not need to duplicate this code, making the X.org code simpler.

    In addition, I believe (but could be wrong) that a lot of the differences between different cards boil down to the mode selection and initialization. if that is moved out of X.org into the kernel the X.org drivers get significantly simplified.

    That isn't the Linux way. All your devices get moved to the new API or they are dropped from the kernel. Can't suck and blow at the same time.
    X.org is not linux, but linux is the most used OS that they are supporting (and X86 hardware by far the fastest changing) so it's not a case of Linux forcing them to do something.

    I would not at all be surprised to see that in a few years the *BSD systems (and x86 Solaris if it is still around) add a compatible KMS interface as well, or be in the situation where new video cards are released, the configuration gets added to Linux, and the cards work great with existing X.org drivers (using KMS), but on systems that do not use KMS they won't work for some significant amount of time until the X.org driver gets enhanced to know about that specific card.

    Comment


    • #47
      Originally posted by greg View Post
      More importantly it allows the X server to run without hardware access, i.e. as a user instead of root.
      The 2D part isn't really the problem in that picture banging registers for displays is not much of a problem, it is the client drivers (ie, the OpenGL and OpenCL clients) that can construct instruction packets to copy system memory around. Those clients construct most of those packets up in userland and so potentially can do nasty things.

      There is still the risk with SEGV's and other escalation techniques, but that is a code quality issue that is partially addressed via other mechanisms (non-exec stacks, etc).

      According to NVidia developers the drivers already implement most of the features of what's known in the free drivers as KMS, but a framebuffer driver is missing.
      KMS is an interface (ioctls, kernel calls, etc) , mode-setting in kernel is a feature. It's close but NV definitely doesn't support KMS.

      Regards,

      matthew

      Comment


      • #48
        Originally posted by mtippett View Post
        KMS and reliable suspend/resume are not directly related, I'd go so far as to say completely unrelated. I'd hazard a guess that it is simply a better driver (ie: banging the bits of the HW), and not a better architecture.
        I think it's a bit more than involved than this. the fact that many video cards have write-only functions where only the process that did the write can know what the state of the card is makes it _very_ hard for the OS to do a reliable suspend/resume because it can't really know the state of the hardware once X has started changing things.

        David Lang

        Comment


        • #49
          Originally posted by mtippett View Post
          KMS and reliable suspend/resume are not directly related, I'd go so far as to say completely unrelated. I'd hazard a guess that it is simply a better driver (ie: banging the bits of the HW), and not a better architecture.

          Yes, I concede it does make it easy that the kernel tells the graphic driver directly that the event has occured. Userland notification is haphazard at best, but with effort can be managed.
          I believe that's the key right there. I'm pretty sure I have seen quotes from the OSS devs saying that it will improve suspend/resume, as a side-effect of having a much simpler hardware management system.

          If AMD really thinks they can work out all that tricky interaction stuff, then more power to them. But the OSS devs don't have the manpower when a seemingly better solution existed. It just makes so much more sense to manage hardware from the kernel rather than some userspace program, at least in my head (Disclaimer: not a video driver developer )

          KMS isn't something I view as all that important by itself, but I would think the binary drivers would also want to implement their own similar system inside their kernel module, just like they have their own alternative to Gallium3D.
          Last edited by smitty3268; 10-20-2009, 09:51 PM.

          Comment


          • #50
            Originally posted by smitty3268 View Post
            I believe that's the key right there. I'm pretty sure I have seen quotes from the OSS devs saying that it will improve suspend/resume, as a side-effect of having a much simpler hardware management system.

            If AMD really thinks they can work out all that tricky interaction stuff, then more power to them. But the OSS devs don't have the manpower when a seemingly better solution existed. It just makes so much more sense to manage hardware from the kernel rather than some userspace program, at least in my head (Disclaimer: not a video driver developer )

            KMS isn't something I view as all that important by itself, but I would think the binary drivers would also want to implement their own similar system inside their drivers, just like they have their own version of a Gallium3D system.
            the ATI drivers are starting to be moved to KMS. second, immediatly after the Intel (who hired many of the developers) drivers

            Comment


            • #51
              Originally posted by dlang View Post
              with KMS the X.org code doesn't need to know how to configure every possible video card in existance. Instead it uses a standard interface to ask the kernel to configure things for it. The kernel already needs to know how to do this to support other things like fb, and text consoles. With KMS X.org does not need to duplicate this code, making the X.org code simpler.
              X.Org doesn't know how to configure every card now. It has a DDX interface. The driver won't be in the X.org repository, but the kernel repository. It's the same developers, so gain neutral. VESA modes (text mode/vesafb) are still standard interfaces. There wasn't really duplication, the X devs were the primary developers of any graphics driver.

              If anything it simplified the non-X drivers (by pushing them out). The X developers now have to deal with X.org _and_ kernel development processes.

              In addition, I believe (but could be wrong) that a lot of the differences between different cards boil down to the mode selection and initialization. if that is moved out of X.org into the kernel the X.org drivers get significantly simplified.
              If it is mode selection and initialization, that moves very slowly (as bridgman has indicates it takes days to weeks to bring up a new card, getting the rest of the universe up is the hard part.

              X.org is not linux, but linux is the most used OS that they are supporting (and X86 hardware by far the fastest changing) so it's not a case of Linux forcing them to do something.

              I would not at all be surprised to see that in a few years the *BSD systems (and x86 Solaris if it is still around) add a compatible KMS interface as well, or be in the situation where new video cards are released, the configuration gets added to Linux, and the cards work great with existing X.org drivers (using KMS), but on systems that do not use KMS they won't work for some significant amount of time until the X.org driver gets enhanced to know about that specific card.
              [/quote]

              Open Source and Linux are not the same. There is a real danger in assuming that Open Source has been solved by the existance of a Linux driver.

              Pushing X into the kernel has marginalized other OSS platforms. This means the Solaris and *BSD will need to have independent drivers. With non-KMS the majority of the basic functionality was common, now it's not.

              Comment


              • #52
                Originally posted by dlang View Post
                I think it's a bit more than involved than this. the fact that many video cards have write-only functions where only the process that did the write can know what the state of the card is makes it _very_ hard for the OS to do a reliable suspend/resume because it can't really know the state of the hardware once X has started changing things.
                Again, the drivers change things, not X.

                You are part way correct, there needs to be a singleton over the hardware. This will be the kernel module. The display portion of the hardware is only one part (and for the most part the easy bit). The hard part is teasing the ASIC back into life. This definitely sits within the kernel, but doesn't need to be anything to do with KMS.

                Realistically, the MS in KMS is focused on as the reason for the change, but there is a truth that there needs to some part of the driver in the kernel, and there already is for KMS, ATI and NV. Without a kernel module suspend/resume is definitely near impossible. The MS (modeset) part is really a matter of driver maintainer choice.

                Regards,

                Matthew

                Comment


                • #53
                  @mtippett

                  Why don't you say just: "Intel inside, idiot outside"?

                  Comment


                  • #54
                    Originally posted by RealNC View Post
                    You don't have the right to want anything. It doesn't belong to you for you to want it. It's theirs, they can do with it whatever they please. This isn't Soviet Russia.
                    Actually, she/he has the right to want anything he wants to want. Whether she/he will get what she/he wants is a different question.

                    Also, this has nothing to do with Russia, but it certainly has to do something with customers being successfully brainwashed by hardware companies.

                    It's perfectly reasonable to expect manufacturers to supply documentation along with the products they sell, so that a customer can actually use the product. If using the product includes programming a device, then manufacturers should supply the documentation that is needed to accomplish this task. That's what computers are made for.

                    Imagine that, starting with tomorrow, every newly manufactured car would be at approximately the level of complexity of a modern pc and car manufacturers would start to tell people that they aren't allowed to modify their cars anymore, because they need to ``protect their intellectual property''.

                    Also, please imagine graphics cards being at such a low level of complexity that it doesn't make sense anymore to not supply documentation along with them, because people could reverse engineer them with no effort anyway. They wouldn't even think about holding back the documentation. They also wouldn't try to excuse their practices by confusing the rest of the world with vague propaganda terms like `intellectual property'. In fact, they wouldn't see the reason for doing that, but instead they would automatically rely on just making good products.

                    If car manufacturers started to act the same way hardware companies do, people would complain, because they're used to being allowed to make modifications to their cars when they want to. In the same way people are used to hardware companies letting them do the computing tasks the companies want them to do on the devices they buy from the companies. That's what using a blob is. Obviously, they are taking advantage of the fact that their products are several orders of magnitude in complexity above cars, making it almost impossible to use them without documentation. But they're used to their customers not complaining about that.

                    Comment


                    • #55
                      Originally posted by n0nsense View Post
                      I don't really care about drivers being binary or open source. They do have the right to keep their little secrets to be able to success on the market.
                      Yes. THEIR code is THEIR secret. That's exactly why people should stop demanding open-source code from nVidia. Instead demand hardware programming specifications. Unlike code, programming specifications need not be kept secret. And the argument that writing specs is a costly affair is crap. They don't need to write specs again; just disclose the specs they provided to the nVidia driver development team. The only reason nVidia won't disclose those specs is because that will antagonize Microsoft.

                      Comment


                      • #56
                        Originally posted by RealNC View Post
                        You don't have the right to want anything. It doesn't belong to you for you to want it. It's theirs, they can do with it whatever they please. This isn't Soviet Russia.
                        Aren't binary drivers a little bit controversial? Maybe this approach is not 100% compliant with kernel GPL. Even if they use LGPL kernel module, it is the same question! Obviously no one wants to untwist this.

                        Comment


                        • #57
                          The kernel developers themselves don't seem to feel strongly about it, and they're the copyright holders. If anyone else wants to "untwist" it, all they can do is declare the combination of Linux+NVidia as resulting in a license violation, meaning they must stop using the NVidia blob. NVidia can offer the blob all they want, but it would be illegal to use it.

                          Comment


                          • #58
                            since linux is a strategic market for them

                            Could they explain how to get two nvidia cards (4 screens) work with xinerama and have 3d and hdtv acceleration working? In windows it has been working forever.

                            Helps welcome ff it is me who does not know how to make it work. Any helping hand would be appreciated

                            Comment


                            • #59
                              Originally posted by RealNC View Post
                              The kernel developers themselves don't seem to feel strongly about it, and they're the copyright holders.
                              Or maybe they don't want to. Or maybe a little bit of both.


                              NVidia can offer the blob all they want, but it would be illegal to use it.
                              I'm not sure about that. Kernel module is obviously derived work from Linux kernel thus I guess it should use same license -> GPL. But using GPL as a license of kernel module permits yourself to create non-GPL driver, hooked onto this module.

                              My personal meaningless opinion is, that everyone looks somewhere else, because nVidia Linux business is so large and important to many users.

                              Comment


                              • #60
                                Originally posted by RealNC View Post
                                The kernel developers themselves don't seem to feel strongly about it, and they're the copyright holders. If anyone else wants to "untwist" it, all they can do is declare the combination of Linux+NVidia as resulting in a license violation, meaning they must stop using the NVidia blob. NVidia can offer the blob all they want, but it would be illegal to use it.
                                A while back (understatement) they removed a few interfaces and made the new ones available by EXPORT_SYMBOL_GPL.

                                I would thinks they only wanted this code being used by GPL-compatible (driver) code.

                                These days it seems not to keep them busy any more... for as far I've read.
                                Last edited by tmpdir; 10-21-2009, 05:34 AM.

                                Comment

                                Working...
                                X