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

  • NVIDIA Tries To Put Fence Sync Into X Server 1.10

    Phoronix: NVIDIA Tries To Put Fence Sync Into X Server 1.10

    X.Org Server 1.10 was just looking to be a big bug-fix release to the X.Org Server with no major features being introduced, up until the merge window was about to be closed. Then last night it was proposed by Keith Packard, the xorg-server 1.10 release manager, to keep it open a few extra days so that he could finally merge the per-CRTC pixmap support. This work alone is nice and is long awaited, but now NVIDIA's James Jones is calling for pulling another feature that's had code available for months: X Synchronization Fences...

    http://www.phoronix.com/vr.php?view=ODg2Mg

  • #2
    this sounds exciting.

    are they working so hard because of wayland? ^^

    Comment


    • #3
      These patches have been out for review since well before all this recent Wayland hubbub.

      Comment


      • #4
        I know nvidia's really not too friendly to OSS on the surface and all, but I hope this code makes it in if it follows procedure/standards and useful for nouveau (and others), and doesn't get held back because of politics.

        Comment


        • #5
          Originally posted by madjr View Post
          this sounds exciting.

          are they working so hard because of wayland? ^^
          My first thought also
          It's probably business as usual though.

          Comment


          • #6
            Originally posted by DanL View Post
            I know nvidia's really not too friendly to OSS on the surface and all, but I hope this code makes it in if it follows procedure/standards and useful for nouveau (and others), and doesn't get held back because of politics.
            I think it is the other way around. The OSS community isn't friendly to nvidia. They invent api calls designed to be unusable for nvidia, because of their binary driver. I wouldn't wonder if the patch will be hacked somehow to only work with KMS and stuff and gets rejected til then.

            Comment


            • #7
              Originally posted by falloutboy View Post
              I think it is the other way around. The OSS community isn't friendly to nvidia. They invent api calls designed to be unusable for nvidia, because of their binary driver. I wouldn't wonder if the patch will be hacked somehow to only work with KMS and stuff and gets rejected til then.
              Are you for real or are you simply trolling?
              "inventing api calls designed to be unstable for nvidia"?

              Have you considered the fact that as an OSS project, Xorg might simply be putting the development <b>open source</b> drivers as their main concern, making a stable API (that might stifle the development of close source drivers) less desirable?
              Oh wait, I assume that you also blame Microsoft for changing the WDM API between releases, right?

              *Sigh*

              - Gilboa
              DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
              SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
              BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
              LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

              Comment


              • #8
                s/might stifle the development of close source drivers/might stifle the development of open source drivers/g
                DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                Comment


                • #9
                  Originally posted by falloutboy View Post
                  The OSS community isn't friendly to nvidia.
                  Ya that's generally how it is.

                  Comment


                  • #10
                    Originally posted by gilboa View Post
                    Are you for real or are you simply trolling?
                    "inventing api calls designed to be unstable for nvidia"?
                    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...

                    Comment


                    • #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 deanjo View Post
                        Ya that's generally how it is.
                        but why ? why they need to fight nvidia ?

                        me for my point i just do not buy nvidia hardware but do not try to hurt nvidia in that way..

                        maybe the FOSS buys should stop fight again nvidia on nvidia hardware and they really should buy amd hardware

                        i really should send Linus an email "buy amd hardware you noob."

                        Comment


                        • #13
                          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).
                          DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                          SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                          BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                          LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                          Comment


                          • #14
                            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
                            DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                            SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                            BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                            LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                            Comment


                            • #15
                              Originally posted by Qaridarium View Post
                              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

                              Working...
                              X