Announcement

Collapse
No announcement yet.

NVIDIA Tries To Put Fence Sync Into X Server 1.10

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

  • #11
    Originally posted by falloutboy View Post
    I didn't say unstable, I said unUSable and was not trolling. If api calls are designed to exclude closed source driver, then you know who isn't friendly to whom...
    Which API calls are designed to exclude closed source drivers?

    Comment


    • #12
      Originally posted by falloutboy View Post
      I didn't say unstable, I said unUSable and was not trolling. If api calls are designed to exclude closed source driver, then you know who isn't friendly to whom...
      I can't speak out of experience about the Xorg API, but at least from the kernel's prospective, you have no idea what you're talking about.
      I'm leading a team that develops a fairly large non-GPL software that runs inside the Linux kernel. Much like the nVidia driver, our software is cross-platform and uses a thin and well-established layer that separates the logic layer from the kernel-support layer.
      I should add that our software uses far more API's than the nVidia driver on one hand (E.g. I/O, files, networking, etc) while doing far less fancy memory management footwork on the other. (Plus, we are 1/5 the size of their module)

      Based on your post, it should be safe to assume that we spend most of our time tracking upstream kernel API changes, but in real life, we rarely spend more than an hour or two when an API does change (once every ~3 kernel releases) - and as I said, we use -far- -far- more API's than the nVidia driver.

      As I said, I don't have experience with Xorg APIs, so I can't really comment outside my domain, but based on my own experience and the API's that I use, the talk about unstable APIs making life difficult for out-of-tree kernel developers is pure FUD.

      And yes, from time to time we do face functions that are GPL-only (and cannot be used by us) - forcing us to develop our own code (E.g. we have our own module loading facility as several symbol loading facility). However, unlike you, I understand the rules of the game: The Linux kernel was designed for in-kernel OSS development and not out-of-tree proprietary kernel development. If I -choose- to live outside the tree and develop non-GPL kernel module, I must also accept the fact that certain functionality is limited or missing and that it's well within the right of the Linux kernel community to prefer OSS in-tree kernel development over me. As the saying goes: Those who live by the sword, die by the sword.

      - Gilboa
      P.S. Windows API changes are usually far more invasive, and require far more work (And yes, service packs can break working kernel code).
      oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
      oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
      oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
      Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

      Comment


      • #13
        P.S. if you read this [1] interview, you'll notice that nVidia is not really concerned about kernel API changes. (Even if they don't like the API's)

        1) The lack of a stable API in the Linux kernel. This is not a large obstacle for us, though: the kernel interface layer of the NVIDIA kernel module is distributed as source code, and compiled at install time for the version and configuration of the kernel in use. This requires occasional maintenance to update for new kernel interface changes, but generally is not too much work.

        That said, the kernel API churn sometimes seems unfortunate: in some cases, working interfaces are broken or replaced with broken ones for no seemingly good reason. In some other cases, APIs that were previously available to us are rendered unusable.
        [1] http://www.phoronix.com/scan.php?pag...qa_linux&num=7

        - Gilboa
        oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
        oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
        oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
        Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

        Comment


        • #14
          Originally posted by Qaridarium
          but why ? why they need to fight nvidia ?
          Politics over practicality, developers wants over end user wants. Why do they have to fight them, they don't, but they choose to because nvidias offering is unpure to them.

          Comment


          • #15
            I think with APIs that lock out closed-source drivers people in general mean DRM and/or KMS stuff.

            Comment


            • #16
              Originally posted by brent View Post
              I think with APIs that lock out closed-source drivers people in general mean DRM and/or KMS stuff.
              Care to share some examples?
              (Beyond the symbol management API's that are GPL-only for obvious reason - they can be used to let a non-GPL modules force-load GPL-only symbols)

              - Gilboa
              oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
              oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
              oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
              Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

              Comment


              • #17
                Originally posted by Qaridarium
                the better way is just Ignor nvidia in any kind of ways
                No, a "better way" is to work together regardless of personal opinion, politics, and ideologies for the greater good of the end user whom more then likely don't care about how it is done but the end result is providing a product that does what the end user wants it to do.

                Comment


                • #18
                  From: Dave Airlie
                  "[...]This goes for nvidia type situations as well, the whole point is
                  to place the maintainer burden at the feet of the people causing the
                  problems in an effort to make them change."
                  Here is the whole thing: http://kerneltrap.org/mailarchive/li...4589722/thread

                  Maybe "not being nice" was the wrong expression, it's more of a not giving a sh*t.

                  Comment


                  • #19
                    The OSS people don't create APIs to be unusable for closed source drivers - they simply don't the burden of trying to maintain compatibility with closed source drivers for no reason other than to keep those drivers running. The kernel APIs should not be held hostage by some binary blob, and in practice there's not much effort in keeping the binary blobs working anyway.
                    It's this way because the devs care about the sanity of kernel interfaces and don't want them bogged down in ancient cruft.

                    Comment


                    • #20
                      Originally posted by mirv View Post
                      The OSS people don't create APIs to be unusable for closed source drivers - they simply don't the burden of trying to maintain compatibility with closed source drivers for no reason other than to keep those drivers running. The kernel APIs should not be held hostage by some binary blob, and in practice there's not much effort in keeping the binary blobs working anyway.
                      It's this way because the devs care about the sanity of kernel interfaces and don't want them bogged down in ancient cruft.
                      Well you would like to think that was the way it worked but we have already seen in the past that Xorg, even though the patch would require virtually no maintenance at all (remember the 3 line patch nvidia submitted that simply gave priority to the blob if detected?). Also you can't say "don't want them bogged down in ancient cruft." as the kernel is full of ancient cruft.

                      Comment

                      Working...
                      X