Announcement

Collapse
No announcement yet.

NVIDIA Working On An EGLStreams Back-End For KDE On Wayland

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

  • #11
    Originally posted by dh04000 View Post
    I hope Nvidia is ready for KWin devs to decide to break the interface that EGLstreams depends on, every....single.....release. Thats how open-source singles out and prevents contributions from anyone they have a beef with.

    And people claim anyone can contribute to open-source if they bring the code, lol. What a joke.
    Any evidence of this? Aside from Martin being stubborn (and he's no longer the lead maintainer) he has, as far as I'm aware, never deliberately broken things

    Comment


    • #12
      I'd say this move is a win-win. Before, there was the whole dichotomy of "should KDE give in to Nvidia for the sake of their users, or stick to principles important to the core of Wayland and the Linux GPU stack?" but seeing as this situation is caused by Nvidia, it makes sense that they're the ones to fix it. I guess none of us really expected that they actually would.
      Let's just hope KDE doesn't get too political and will actually accept these changes (assuming they're coded well).

      Comment


      • #13
        Even if Nvidia submits the patches it still incurs a maintenance cost since now 2 code paths have to be tested for every release. Supporting the 'next gen' buffer allocation mechanism would have been a much better solution.

        Comment


        • #14
          Originally posted by msotirov View Post
          Woah, is it April 1st already?
          Yep, that was my first thought as well.

          If Nvidia continues to contribute like this, I may even start buying hw from them again (in time).

          Comment


          • #15
            Originally posted by FireBurn View Post

            Any evidence of this? Aside from Martin being stubborn (and he's no longer the lead maintainer) he has, as far as I'm aware, never deliberately broken things
            Or to put it another way, never ascribe maliciousness to that which can be explained by incompetence.
            Last edited by Slartifartblast; 14 November 2018, 10:56 AM.

            Comment


            • #16
              Since it's EGL based does it mean the compositor will only be able to use OpenGL and never Vulkan?

              Comment


              • #17
                Ugh. I'm annoyed that people are giving in to NVIDIA's crap. They really need to stick it to NVIDIA and demand that they work for a common solution. Can't keep doing this work for every single toolkit and compositor.

                Comment


                • #18
                  Good thing KDE stood its ground!
                  If NV decides to not adhere to standards, it's their burden to support their isolated solution.

                  Comment


                  • #19
                    The big problem here is Wayland itself. EGLStreams is a device driver API. It does not belong ANYWHERE near a window manager code. If you are using X, EGLStreams can be built right into X Server and only the X server would need to deal with it, the window managers would not need care. So, add it once to the X server, and you get instant support for EGLStreams for the 100s of window managers in existance.

                    This is why the entire Wayland concept should be scrapped and we should go back to a pure X11 centric model. Wayland is fatally flawed because it fails to maintain the vital Window Manager-Window System separation. The idea that every window manager now needs backends for drivers is an insane concept. You didnt have to worry about this on X because the device drivers were in the X server and therefore the X server was a great compatibility feature, the device drivers only need to be interfaced once into the X server, and every Window Manager uses the same X server. Applications and Window managers are isolated from any contact whatsoever with hardware device drivers. This is how things should be.

                    I am talking about the traditional X model here, including the GLX protocol, and NOT DRI/DRM crap that infested things later. The original X model of having the X server solely in charge of handling the device drivers is the right way. The wrong way is putting window managers in charge of hardware and even more insanely putting every single application in charge of the hardware. With Wayland you have the window manager, and all applications directly vying for control over the same GPU hardware, this is a recipe for disaster.

                    Some have said that the X11 model anyway had applications talking to video drivers directly. This is incorrect. Under the traditional X client/server model, applications would not be anywhere near driver code, they sent all of their graphics commands over X protocol, including GLX, to the X server. The X server has the video drivers and can use its own accelerated drivers to send OpenGL commands onto the GPU. This is called AIGLX, Accelerated Indirect GLX and it is clearly by far the best model. ONLY in the case where DRI/DRM is used would an X application have video card drivers, but AIGLX can be used instead of DRI/DRM.


                    Another misconception is that X11 applications are not network transparent. The fact is, under the traditional X11 model, using AIGLX, they are. Any X application that is PROPERLY WRITTEN operates perfectly well over a network transparent SSH port forward. Now, it is true that if you are running an application on the same computer as the X server, the application can switch to using MIT Shared Memory, however, any PROPERLY IMPLEMENTED application is designed to use this only when available, otherwise it uploads image data to the server over X stream protocol. The X Render extension SHOULD work perfectly well under this model if an application can upload its images and then composite them together on the server. You should also be able to create a server side pixmap and render opengl to that using AIGLX and then composite pixmaps together for display. There have been at various times effors to incorporate compressed image and video decoders on the X server side, so that X applications can upload image and video data in compressed form to the X server. This would be done with seperate sandbox processes for the actual decoders rather than in the main X server process.

                    To improve X security, it has been suggested to implement a fine grained security model that can give certain clients more rights, such as screen readers and screenshot utilities, but would restrict normal X clients to their own windows.

                    The KMS disaster was due to an ill concieved attempt to "fix" the problem that if the X server crashed, it would corrupt the display. This was because if the user wanted to switch to command line, the X server would restore the graphics device mode to textmode, rather than the kernel. If the X server crashed, that would not happen, so it was thought to put a video driver into the kernel so the kernel can do that. Now first of all, X crashes today are very rare but were usually the result of a bad driver. Since it is a bad driver usually to blame, putting part of the video driver in the kernel will cause the entire kernel to crash rather than just the X server. The best way to address this problem is to have a modesetting driver instead in a seperate user process, which the terminal drivers and the X server would then communicate with.

                    With all of this, you can get every feature you need for good video and graphics support without all of the DRI/DRM/Wayland junk.



                    Comment


                    • #20
                      It's not so unexpected. Nvidia maintains an EGLStreams patched version of the Wayland Weston reference compositor as well.

                      What really needs to happen is hardware accelerated XWayland support using the Nvidia proprietary driver. It appears that games will render on XWayland with Nvidia drivers but last I checked, it was with super slow software rendering. IMO, Wayland is DOA for Nvidia users (like myself) until XWayland is properly supported.

                      Michael, any status update on that front?

                      Comment

                      Working...
                      X