Announcement

Collapse
No announcement yet.

NVIDIA's List Of Known Wayland Issues From SLI To VDPAU, VR & More

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

  • #71
    Originally posted by mdedetrich View Post
    The linux devs are wrong in this regard, no one is right 100% of the time. If you bothered to read mailing list discussions they stuck to implicit sync for a number of reasons that ended many of which are invalid. Even the concept of implicit sync was chosen as a default because it fits into Linux's/Unix's "everything is a file with input/output buffers model" nicely which works until it doesn't.

    Of course NVidia's listened to the dev's arguments, but as has been said like 7 times already the Linux devs can argue as much as the cows go home but NVidia is not going to recode their entire driver for an OS that has <2% desktop market share especially considering that every other operating system doesn't enforce this use of implicit sync (I am talking Windows, Android (who rebuilt their own graphics stack), MacOSx. NVidia's driver is actually cross platform driver which means its Linux (and I guess Unix but they were never serious about desktop) which is the odd one out here
    Does Nvidia support the Android version of explicit sync the on desktop platforms answer is no it does not. Nvidia embedded platforms like you find in the switch does support implicit sync over the explicit sync without major overhead under Linux its also a open driver and has been for over a decade. MacOS and Android version of explicit sync does all you to implement implicit sync on top of it without insane over head. One of the reason why MacOS does not have Nvidia driver support is arguement over this sync problem because they wanted legacy applications still to be able to work.

    Thing to remember they were able to prune the list of reasons why implicit sync is required. The show stopper is legacy application support and that cannot be removed.

    Originally posted by mdedetrich View Post
    Sigh, again someone commenting on something they don't understand. If you have explicit sync, you can implement implicit ontop.
    This is not true and that the problem. If your explicit sync cannot be waited for its current status to change you have a performance problem. If you have to repeatedly polled for current status you start having the 30%+ overhead problem to not being able todo it at all due to stalling out the GPU/CPU.

    The way Nvidia has implemented their explicit sync does technically allow faster but it also does force polling of status. AMD and Intel and arm and Nvidia embedded you can put the explicit sync status in the shared memory between the GPU and CPU for those that you are need implicit sync so you are not having to poll the card so not having massive overhead.

    Nvidia desktop driver has a issue at the lower level. Yes more of the Linux graphics stack will over time come explicit sync but implicit sync will stay their for legacy applications. You see it in KDE where the Nvidia developer hit somewhere that was code implicit sync and the stuff just does not work and it was lets recode this section to explicit sync ignoring applications exist built prior that expect implicit.

    Remember you said Linux had the Unix model everything is a file. Even explicit is transferred around by files. Also remember you said this came from Unix

    Something else key. Glamor is legacy code. Glamor starts developing in the 1990s as opengl backend to X11 server back then opengl only had implicit sync. That is not your coffin digger. Glamor is implementation X11 2D drawing to specification this is the 1980s and before so from the Unix world and only designed with implicit sync.

    mdedetrich remember Nvidia says you do implicit sync on their hardware with the way they have done explicit sync it either going to perform badly or the opengl functions that are implicit sync will not be there so your application will not run at all. Yes there are a lot of legacy parts that are still in Linux installs today that are like Glamor where what they implement was set in stone before the first line of the Linux kernel was written.

    Like it or not we have a rock and hard place. If nvidia is not going to recode their driver we still need a decently performing implicit sync done in userspace for the legacy programs that include glamor and all application using old X11 2D rendering and early opengl applications and early egl applications because all of them mandate implicit sync. Yes the 30%+ growing over head to do implicit sync on Nvidia hardware is kind of a problem do note AMD, Intel, Arm... all do not have this problem their driver have a large amount explicit sync yet when you do implicit sync on top it you have at worst a 5% overhead at best zero overhead.

    The fact that some cases of implicit sync with AMD and Intel implementations have zero overhead and then Nvidia says that that area is a performance problem has kind of got them ignored as well. This NIH(Not Invented Here) Nvidia goes and makes arguments only based on their hardware they don't go and check if the problem is unique to their hardware.

    Legacy application support is one of the reasons why Apple dropped Nvidia. The Nvidia point of view that performance no matter the cost is not compatible with those making operating systems attempting to run legacy applications. Nvidia point of view that their implementation is always right so not having to consider what the platform maker need is also what lost them different console contracts.

    It is possible that Nvidia has make a mistake at silicon level causing this problem. I would really suspect Nvidia make a mistake a silicon level for how they have implemented explicit sync since Intel, Amd, arm... hardware explicit sync when you implement implicit sync on top of does not have massive overhead something is unique to what Nvidia has done. And it is possible that if this is a silicon fault this could mean for legacy applications you need Intel/AMD graphics because Nvidia silicon is just not suitable.

    Comment


    • #72
      Originally posted by wertigon View Post

      Not sure if trolling, or simply confunded. According to you:

      * Nvidia driver is based on explicit sync
      * Implementing implicit sync support in that driver would require a recoding of all the driver
      * Yet, somehow, magically, "If you have explicit sync, you can implement implicit ontop"
      They are all correct, although with the 3rd point we are talking about not the driver but graphics API's that need to be implicit sync (such as your OpenGL example).

      If you want more explanation, just read the thread that was posted earlier. There is no point repeating myself here.

      Comment


      • #73
        Originally posted by mdedetrich View Post
        They are all correct, although with the 3rd point we are talking about not the driver but graphics API's that need to be implicit sync (such as your OpenGL example).

        If you want more explanation, just read the thread that was posted earlier. There is no point repeating myself here.
        Except there is a problem here you use Nvidia provide driver with opengl example code designed for implicit sync as per the opengl standard you get graphical artefacts(errors) because Nvidia does not in fact implement implicit sync properly even under X11 or Windows. Yes 2d X11 graphics drawing has had artifacts when using Nvidia only driver on bare metal X11 for over 15 years now.

        This is why your idea that you can implement implicit sync on explicit sync does not match what Nvidia does. Nvidia says they will not implement implicit sync because it has too much performance cost. Basically Nvidia does not want to lose benchmarks. Yet somehow AMD with explicit sync with support for implicit sync is able to perform quite well.

        The reality here Nvidia has not been putting up examples of how to do implicit sync when you need it. Not when you want it when you absolutely need it so applications function correctly. There is a lot of stuff you have to support that is no where near new.

        The reality here if Nvidia just provided how to do implicit sync when required even vulkan this would allow zink to do it well enough then have glamor run on that and possible in time replace glamor with something written for vulkan.

        The reality is like it or not implicit sync is required. Linux core developers are going to be asking how do you do implicit sync and Nvidia needs to have a functional real world examples. Not everything can be converted to explicit sync code no matter how badly we want it.
        Last edited by oiaohm; 24 May 2022, 09:38 PM.

        Comment


        • #74
          Originally posted by oiaohm View Post

          Except there is a problem here you use Nvidia provide driver with opengl example code designed for implicit sync as per the opengl standard you get graphical artefacts(errors) because Nvidia does not in fact implement implicit sync properly even under X11 or Windows. Yes 2d X11 graphics drawing has had artifacts when using Nvidia only driver on bare metal X11 for over 15 years now.

          This is why your idea that you can implement implicit sync on explicit sync does not match what Nvidia does. Nvidia says they will not implement implicit sync because it has too much performance cost. Basically Nvidia does not want to lose benchmarks. Yet somehow AMD with explicit sync with support for implicit sync is able to perform quite well.

          The reality here Nvidia has not been putting up examples of how to do implicit sync when you need it. Not when you want it when you absolutely need it so applications function correctly. There is a lot of stuff you have to support that is no where near new.

          The reality here if Nvidia just provided how to do implicit sync when required even vulkan this would allow zink to do it well enough then have glamor run on that and possible in time replace glamor with something written for vulkan.

          The reality is like it or not implicit sync is required. Linux core developers are going to be asking how do you do implicit sync and Nvidia needs to have a functional real world examples. Not everything can be converted to explicit sync code no matter how badly we want it.
          Dude but sorry I don't trust anything you say about NVidia and OpenGL, you falsely claimed that their OpenGL driver is not properly conformant when in fact it was the first officially conformant driver.


          When you stop answering everything front he frame that "NVidia is wrong" let me know.
          Last edited by mdedetrich; 25 May 2022, 04:23 AM.

          Comment


          • #75
            Originally posted by mdedetrich View Post

            Dude but sorry I don't trust anything you say about NVidia and OpenGL, you falsely claimed that their OpenGL driver is not properly conformant when in fact it was the first officially conformant driver.
            They aren't conformant with anything older. Try running any game that utilise OpenGL 3.0 or earlier. The evidence is *literally* right there.

            Comment


            • #76
              Originally posted by wertigon View Post

              They aren't conformant with anything older. Try running any game that utilise OpenGL 3.0 or earlier. The evidence is *literally* right there.
              Thats because games don't correctly use the OpenGL API and so a lot of drivers have to hotpatch games so they even run correctly. The same problem also applies to DirectX which is why even projects like dxvk have had to add per game hotpatch configurations to get them to run https://www.phoronix.com/scan.php?pa...r-Game-Configs .

              If you want a OpenGL 3.x certified system you need to get a specific drivers for that and typically with NVidia that is quadro cards that have been certified. Then again with those Quadro cards you will get problems running certain games if you use the Quadro driver. These drivers have to be certified because Quadro cards are used for workstation machines that have CAD style products (and those have to be certified).

              This is one of the main advantages with Vulkan, unlike OpenGL/DirectX where improperly coded games could run because warnings were largely ignored, Vulkan will not run any game if the game produces warnings. It forces the game devs to actually properly write the game.

              Its a bit shitty that NVidia made a business model around this with their Gameready drivers but that is just a result of the a badly designed underlying API (which is badly designed because it was made in the 90's and a lot of the problems OpenGL was trying to solve back then aren't applicable today).
              Last edited by mdedetrich; 25 May 2022, 06:53 AM.

              Comment


              • #77
                Originally posted by oiaohm View Post


                This is why your idea that you can implement implicit sync on explicit sync does not match what Nvidia does. Nvidia says they will not implement implicit sync because it has too much performance cost. Basically Nvidia does not want to lose benchmarks. Yet somehow AMD with explicit sync with support for implicit sync is able to perform quite well.
                Dude stop making up shit, the reason why NVidia doesn't want to put implicit sync in their driver is because their current driver is completely built around explicit sync, it has nothing to do with them "losing benchmarks". They would have to re code significant parts of their million code line driver and then do all of the testing (and testing part is going to be massive with implicit sync because thats the problem with implicit sync, a lot of the assumptions about how the "implicit" part in implicit sync has to be designed and tested). This is simply put not going to happen, and if you want it to happen you will wait for a decade (minimum). Ontop of that as mentioned previously its also stupid on a technical level because its an inferior design (in the context of GPU's). Even AMD and Intel agree on this (Ekstrand is former Intel graphics maintainer and is now at Collabora working on Mesa).

                If you are asking why AMD/Intel driver has implicit sync and NVidia doesn't, its simple, they coded their drivers with implicit sync where as NVidia didn't (or to be more accurate, ever since WDDM in Vista days NVidia rebuilt their entire drivers from scratch without any implicit sync. This was largely also the reason why their drivers were unstable in the Vista days until they ironed out the problems).

                You guys can cry and whine all day long about why NVidia doesn't have implicit sync but the reason is simple, NVidia completely dropped implicit sync in their driver over a decade ago and again asking them to recode their driver to support implicit sync is like asking the Linux dev's to recode their entire kernel in Rust, its just not gonna happen.

                And yes, you can put implicit sync workarounds on top of explicit sync but because its happening on the boundaries of the driver level for the specific places in context (i.e. glamor) that we are talking about doing so has massive performance issues and/or it requires a lot of workarounds. The precise technical of why and how have been stated in the mesa thread, just god damn read it.

                I mean NVidia already tried to do what the mesa guys told them to do in terms of adding implicit sync work arounds ontop of their driver and they said it just doesn't work and they told precisely why. And yes, even Ekstrand is defending NVidia in this regard because none of the workarounds mentioned make any sense. What more do you want? NVidia rebuilding their driver is not an option, the implicit sync workarounds ontop of their driver was a possible initial solution but we now know that they create more problems then they solve. Those are the facts on the ground.
                Last edited by mdedetrich; 25 May 2022, 09:11 AM.

                Comment


                • #78
                  Originally posted by mdedetrich View Post

                  Dude stop making up shit, the reason why NVidia doesn't want to put implicit sync in their driver is because their current driver is completely built around explicit sync. They would have to re code significant parts of their million code line driver and then do all of the testing. This is simply put not going to happen, and if you want it to happen you will wait for a decade (minimum). Ontop of that as mentioned previously its also stupid on a technical level because its an inferior design.

                  If you are asking why AMD/Intel driver has implicit sync and NVidia doesn't, its simple, they coded their drivers with implicit sync where as NVidia didn't (or to be more accurate, ever since WDDM in Vista days NVidia rebuilt their entire drivers from scratch without any implicit sync. This was largely also the reason why their drivers were unstable in the Vista days until they ironed out the problems).

                  You guys can cry and whine all day long about why NVidia doesn't have implicit sync but the reason is simple, NVidia completely dropped implicit sync in their driver over a decade ago and again asking them to recode their driver to support implicit sync is like asking the Linux dev's to recode their entire kernel in Rust, its just not gonna happen.
                  Ergo, Nvidia is locked in to an explicit sync model, while everyone else is not. Yes? Again, the facts:

                  * Nvidia requires explicit sync to be mainlined
                  * AMD does not require explicit sync to be mainlined (though would welcome the performance boost)
                  * Intel does not require explicit sync to be mainlined (though would welcome the performance boost)
                  * Qualcomm does not require explicit sync to be mainlined (though would welcome the performance boost)
                  * ARM does not require explicit sync to be mainlined (though would welcome the performance boost)
                  * Rest is too small to matter and most does not require explicit sync to be mainlined (though would welcome the performance boost)

                  I understand perfectly well that Nvidia has painted themselves into the explicit sync corner and bet the farm on that. Fine. I can accept this fact. Now the question, how do we get legacy shit working on a driver that explicitly does not support legacy shit?

                  Originally posted by mdedetrich View Post
                  And yes, you can put implicit sync workarounds on top of explicit sync but because its happening on the boundaries of the driver level forthe specific places in context (like Galium) that we are talking about doing so has massive performance issues and/or it requires a lot of workarounds. The prices technical of why and how have been stated in the mesa thread, just god damn read it.

                  I mean NVidia already tried to do what the mesa guys told them to do in terms of adding implicit sync work arounds ontop of their driver and they said it just doesn't work and they told precisely why. What more do you want?
                  It is perfectly simple.

                  * Nvidia needs explicit sync to be implemented.
                  * Linux devs have said, fine. Draw up a plan and we'll collaborate on that.
                  * Nvidia gives said plan. It is incompatible with the rest of the ecosystem.
                  * Linux devs then say, "We cannot do this because it breaks userspace compatibility, hard. Especially with other vendors. Tear it up, do it again, and make it right this time."
                  * Nvidia pushes back and tries to claim it won't break compatibility.
                  * Linux devs remain adamant that yes, these changes will not work for everyone. Make it work for everyone.
                  * Nvidia is still contemplating their next move.

                  Linux devs are not the sort of people to hold grudges and welcome any and all collaboration done on the Linux devs terms. It is o.k. to be bad at collaborations and not meeting the strict requirements set here. But please realize Nvidia is not the only stakeholder or even the most important contributor to the Linux kernel. Only Nvidia have any interest in getting the support for this into mainline.

                  I agree the changes have technical merit. But not so much merit that it has priority over everything else. Except for Nvidia. So, from the perspective of the devs, If Nvidia needs this then it is only fair Nvidia does the work!

                  Patches welcome. Collaboration welcome. Make it work for everyone. Case closed.

                  Comment


                  • #79
                    Originally posted by wertigon View Post

                    It is perfectly simple.
                    * Linux devs have said, fine. Draw up a plan and we'll collaborate on that.
                    * Nvidia gives said plan. It is incompatible with the rest of the ecosystem.
                    * Linux devs then say, "We cannot do this because it breaks userspace compatibility, hard. Especially with other vendors. Tear it up, do it again, and make it right this time."
                    This is wrong, no one (including NVidia) came up with a plan to break userspace. Stop pulling out shit from your ass, I don't know why you keep on repeating this (apart from the fact that your whole argument falls apart otherwise).

                    The only exception I can think of is X11 explicit protocol but that in its current state is broken and because of that no one actually uses it.

                    This was also directly stated here https://gitlab.freedesktop.org/xorg/...7#note_1275874

                    While OSS driver stacks have supported Wayland and GBM for years, the fact is our driver already requires a more or less bleeding-edge set of supporting OSS components to support these use cases, so it doesn't necessarily need to be burdened by backwards compatibility with a host of older implicit-sync-only userspace or kernel components. They already aren't going to work for other reasons.
                    No one is trying to suggest code that will break current usecases unless those usecases are so broken that no one is even using them.
                    Last edited by mdedetrich; 25 May 2022, 07:57 AM.

                    Comment


                    • #80
                      mdedetrich, You seem to be more willing to point the finger on who is to blame here, than actually provide solutions.

                      You are arguing semantics. Even if it is true that Nvidia code doesn't break userspace, but instead just force every other stakeholder to go out of their way to appease Nvidia, this still isn't a viable solution.

                      Nvidia has the incentive and initiative here, therefore if Nvidia wants to resolve this quickly they need to start collaborating with the rest of the vendors on an API or set of API changes that resolve their issue, is backwards compatible and does not (significantly) hurt their competitors. If the Nvidia solution require more than 40 hours of development time from any competitor then there is a strong chance it will be vetoed down.

                      Meanwhile their competitors will slowly move towards a solution that may or may not be compatible with Nvidias hardware design. Nvidia is free to collaborate on that, of course.

                      It is up to Nvidia if they want to stay compatible and collaborate. Any effort to do so is encouraged, but failure to do so will mean the rest of the world moves on regardless.

                      Comment

                      Working...
                      X