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

  • #21
    It's good to have addressed about the limitations to fix. Nvidia article alludes to R515 driver, so my question deals with the possibility thhese limitations affect the owner driver too, as I assume.
    Last edited by Azrael5; 22 May 2022, 12:46 PM.

    Comment


    • #22
      So your bets, gentlemen, when are we going to have full open driver stack for Nvidia?

      Comment


      • #23
        So "stubborn NVIDIA" became "passive aggressive NVIDIA" LOL

        Comment


        • #24
          Originally posted by birdie View Post
          And surely HDR works in mutter and Kwin under Wayland, right? What, it doesn't? I mean more than a decade ago Windows Vista already supported HDR displays near perfectly and in Wayland it's just "Wait a little bit more?"
          As a recent Windows convert and still needing it for some games, with a HDR display. I can assure you that what you said is not only false on timeline, but false in general. HDR was only recently supported (Couple years) in any format that was usable, and further, is still VERY VERY buggy and prone to complete failure even today. It is HARDLY in a production ready state and more a novelty that works....somewhat. You need to tone the rhetoric down my man.

          Comment


          • #25
            I assume that birdie's goal is to collect information to hack wayland

            Comment


            • #26
              Originally posted by RejectModernity View Post
              So your bets, gentlemen, when are we going to have full open driver stack for Nvidia?
              I guess NVIDIA and others (birdie) will claim when Wayland is ready

              Comment


              • #27
                Originally posted by Kivarnis View Post

                As a recent Windows convert and still needing it for some games, with a HDR display. I can assure you that what you said is not only false on timeline, but false in general. HDR was only recently supported (Couple years) in any format that was usable, and further, is still VERY VERY buggy and prone to complete failure even today. It is HARDLY in a production ready state and more a novelty that works....somewhat. You need to tone the rhetoric down my man.
                HDR initially had nothing to do with games but everything to do with wide color depth, i.e. 30/36 bit displays which Vista indeed supported. I'm not stupid, crazy or say imbecilic things.

                And I'm sorry to break it to you but HDR under Linux is in a state of poo poo. It doesn't work under Xorg (too many applications are completely broken), it's not supported under Wayland. It's 2022 and we've had such monitors for more than a decade now.

                Your issues with HDR are not about Windows not supporting it but about multiple HDR standards and implementations which are hella difficult to get right. Except in Linux of course where HDR plain doesn't exist.

                Comment


                • #28
                  Originally posted by RejectModernity View Post
                  So your bets, gentlemen, when are we going to have full open driver stack for Nvidia?
                  AMD has never released the sources for their AMD Pro Linux drivers, so I'm 99.999999% certain NVIDIA won't release theirs.

                  What we could get is Mesa's Nouveau implementation talking to new open source NVIDIA drivers which was actually how NVIDIA announced it would happen from then on. But that's gonna take a lot of time, I guess years.

                  Comment


                  • #29
                    Originally posted by piotrj3 View Post
                    Half of Wayland's issues you listed are not Nvidia's fault. They are fault that simply a lot of linux stack is implicit sync made and nvidia driver is explicit sync. And that issue would be solved by EGLstreams and actually Intel engineer said that even somewhere.
                    No that is not the case. The reality is all first point Nvidia raises they say need new EGL extentions guess what this is not duplicate Extensions with what EGLStreams support its that EGLStreams never supported that. Second point there has never been a interface for RTD3 power management other than the Nvidia hidden one. The Display multiplexers not supported by Nvidia EGLStreams either.

                    So so that half nothing todo with Implicit sync or explicit sync and is purely Nvidia not implementing what is need.

                    Next is Glamor
                    https://www.freedesktop.org/wiki/Software/Glamor/
                    This is meant to be a fall back if the vendors 2D accelerated driver does not work.
                    • Xwayland does not provide a suitable mechanism for our driver to synchronize application rendering with presentation, which can cause visual corruption in some circumstances.
                    • Indirect GLX does not work with Xwayland because the Glamor rendering engine is not compatible with our EGL implementation.
                    • Hardware overlays cannot be used by GLX applications with Xwayland.
                    Except these are not Wayland problems these are general X11 server problems. Glamor does not work properly on Nvidia Opengl implementation under bare metal X11 either.

                    Wayland exposes the problem by removing the option of vendor 2D driver in X11 server not that the problem did not exist anyhow. Yes this could relate to Implicit sync and explicit sync. But glamor has for it complete development been open source.

                    EGL_EXT_platform_x11 is not supported with Xwayland.
                    This one has nothing todo with Xwayland really so they put it in driver issues. No application has been found that depends on that Extension. The only thing so far that is documented that depends on that extension is the Nvidia driver. Note Nvidia did not put this one in the Wayland compositor or protocol list because its not.

                    Originally posted by piotrj3 View Post
                    Also tons of bugs comes from that devs are using intel/AMD being of open source driver stack and that means during development things gets tested automatically against those drivers. Nvidia does not have this privilage and this is not Nvidia's driver poor quality. If you asked any opengl/Vulkan developer who has the best opengl/vulkan driver they would say Nvidia and say there were more issues with AMD/Intel.
                    Nvidia has chosen not to take part in X11 stack development. Redhat, AMD and Intel at different times have provide X11 Server with lead developers Nvidia never has.

                    The reality is majority of Nvidia list is simply Nvidia driver issues and lack of community involvement. Please note we saw the same thing between Nvidia and Microsoft over Vista graphics stack change except with Linux Nvidia has held their ground longer than the 3 years with Vista.

                    Any ideas why DRI2 explicit sync went away with DRI3. Yes it was a Intel developer who did that change after finding something . In DRI2 you had GEM that had all the buffers on the GPU exposed to all applications this is a security problem. Explicit sync allows you to snoop on what other applications are doing. Yes Nvidia implementation of Explicit sync is just as flawed as the old Intel DRI2 one was. Implicit sync is required for security reasons. Other parties who are not Nvidia providing graphics drivers on Linux after seeing what the Intel developer found have been providing implicit sync this include other closed source drivers used in embedded who have really small development teams.

                    Not being involved in the open source graphics stack has put Nvidia behind in security discoveries like the Explicit sync flaw. Yes the Nvidia driver on Linux and Windows contains no counter measure against it. Yes the counter measure does involve implementing implicit sync so you don't have to use Explicit sync all the time and that you can show applications only the buffers they need to know about and only what is happening to those buffers they need to know about so no snooping.

                    Comment


                    • #30
                      Originally posted by birdie View Post
                      HDR initially had nothing to do with games but everything to do with wide color depth, i.e. 30/36 bit displays which Vista indeed supported. I'm not stupid, crazy or say imbecilic things.
                      That is one of the changes that lead to Nvidia not supporting Vista with properly working graphics drivers for 3 years. Yes part o dealing with HDR is getting all the graphics driver vendors on the same page on the problem. Having AMD/Intel with one set of ideas and Nvidia with a different set and ARM with a different set has made doing HDR on Linux hard. Yes the same problem existed in Windows XP HDR implementations where they were GPU vendor unique and broken to hell.

                      Hurding cats problems. With Nvidia open sourcing their kernel driver we are starting to get the cats some what hurded so we might be able to get somewhere on lots of different features.

                      Yes mainlining into the Linux kernel has a reduce duplication process and uniform interfaces this will be a horrible complex step for Nvidia because they are last to the party.

                      Originally posted by birdie View Post
                      AMD has never released the sources for their AMD Pro Linux drivers, so I'm 99.999999% certain NVIDIA won't release theirs.

                      What we could get is Mesa's Nouveau implementation talking to new open source NVIDIA drivers which was actually how NVIDIA announced it would happen from then on. But that's gonna take a lot of time, I guess years.
                      https://nouveau.freedesktop.org/FeatureMatrix.html The open source Nvidia drivers are NV160 and newer that is Turing GeForce RTX 2060, GeForce GTX 1660. The released power management firmware could make Turing cards useful quite with the open source driver reasonably quickly because a large amount of the work is already done. Please note this is not use the Nvidia released driver but use the existing Nouveau driver with the released firmware.

                      Yes you are right AMD never open sourced their pro drivers but it was possible for open source developers to ask questions and get answers from the AMD developers working on the pro drivers with any odd behavour. Yes possible and horrible with having legal department in the middle. Time will tell if Nvidia allows this.

                      It would have been good if Nvidia was releasing firmware for older cards under a shippable/usable license by the open source drivers. Not the existing license that say must be used with the Nvidia stack. Of course this has not stopped developers from extracting the firmware from the closed source Nvidia graphics drivers and using this anyhow this is why Turing is so far along. But you legally cannot do that for end users as a distribution this is why its required a Nvidia change.

                      The early Nvidia cards did not require signing on the firmware the reason why they work so well is that the open source developers went and created their own firmwares for the cards. Signed means you cannot do this so stalled out Nouveau development. So we could see a revive in Nouveau development from super computers and other things again. Yes the cases where having the drivers fully validated is important.

                      Do note its the compute cards Nvidia has supported first as well not the desktop ones. There is a serous issue that those parties want open source drivers and the open source driver release is to stop Nvidia from bleeding contracts into the future as fast as Intel enters the game and AMD gets decent.

                      Comment

                      Working...
                      X