Announcement

Collapse
No announcement yet.

X.Org Server 1.20 RC4 Released, EGLStreams For XWayland Might Still Land

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

  • #51
    Originally posted by GizmoChicken View Post

    Agreed!

    And what’s with all the package formats? We only need one package format. And because only I know what’s best, that one package format must be the one package format that I use! Sucks to be anyone but me!

    And what’s with all the interface toolkits? We only need one interface toolkit! And because only I know what’s best, that one interface toolkit must be the one interface toolkit that I use! Sucks to be anyone but me!

    And what’s with all the desktop environments? We only need one desktop environment. And because only I know what’s best, that one desktop environment must be the one desktop environment that I use! Sucks to be anyone but me!

    And what’s with all the . . .

    /s

    * Original quote edited by GizmoChicken.
    I'm not saying we should only have one format. I'm saying it should not be incumbent on everyone else to support Nvidia's bs.

    Comment


    • #52
      Originally posted by kaprikawn View Post

      I'm not saying we should only have one format. I'm saying it should not be incumbent on everyone else to support Nvidia's bs.
      You wrote that "Nvidia should be forced to support GBM like everyone else" which sounds to me like you would permit only GBM, and would oppose EGLStreams no matter who does the work to support it.

      But in any case, even in you are not opposed to EGLStreams, I find it nearly as troubling that you wish to prohibit Adam Jackson from working on the project of his choice.

      Comment


      • #53
        Originally posted by You- View Post
        I would suspect that the vast majority of desktop machines do not have nVidia - just intel with integrated graphics.
        Exactly. Also, last time I checked most home users have bought laptops in the past 5-6 years or so and most laptops have Intel cards. Only very few high-end laptops have nVidia or AMD cards.

        Comment


        • #54
          Originally posted by dkasak View Post
          Where is the motivation for nVidia to follow through on their promises if this is merged? As for lack of accelerated nVidia support hurting Wayland adoption ... ha ... not likely. Wayland adoption will pick up when all the major *functionality* falls into place ... which will be pretty soon, hence distros planning to flip to Wayland by default. nVidia users will either have to deal with software rendering, or switch back to X by default. So a handful of Linux users with nVidia GPUs will not be using Wayland, sure. That's really not the end of the world, and in no way stops the majority of Linux users from moving on.
          If they want better performance, they can always switch to Arcan (AFAIK it works with nVidia cards as well).

          Comment


          • #55
            Originally posted by indepe View Post
            Perhaps Khronos should define a standard for "device memory allocation" and make it part of OpenGL 4.7 and Vulkan 1.2.
            Already done. EGL_KHR_stream ( https://www.khronos.org/registry/EGL...KHR_stream.txt ). Unfortunately, opensource community doesn't want to support it, prefers nonstandard GBM.

            Comment


            • #56
              Originally posted by RomuloP View Post
              And this is my point, why don't it support protocols in terms of modules or any encapsulation that
              FYI: the kernel already does allow out-of-tree modules, you can find many out-of-tree drivers, the most notable one being NVIDIA's, or Virtualbox's or VMWare's, or Broadcom's wifi drivers for PC users.

              The trick is that the API/ABI used for drivers is subject to change (and usually does change) between releases, out-of-tree modules will have to be adjusted to these changes to keep working, thus requiring some kind of constant maintenance. While the in-tree drivers will be migrated to the new API/ABI by whoever does the change in the kernel (i.e. with no burden on the driver developer).

              But this isn't terribly hard to do, for most things.

              avoid this excuse of "it is not sane to accept those kind of patches because it is not free/need to be maintained/etc". I really don't get people that are pro "don't accept".
              The Linux kernel project was funded on some rules about code quality/maintainability and copyleft opensource, if contributions don't follow them they won't be merged and will have to stay out-of-tree, maintained by third parties.

              I don't see how this is difficult to understand, or bad.

              Comment


              • #57
                Originally posted by Britoid View Post
                Isn't GBM part of Mesa? Which makes it somewhat a vendor implementation, so what means its automatically better than nVidia's EGLStreams?
                Who is the vendor?
                Mesa is used by all opensource 3D drivers. Intel, AMD, Freedreno, VC4 (raspberry pi), Etnaviv, and whatever.

                Comment


                • #58
                  Here's what I don't get:

                  Nvidia is already working on a unified device memory allocation API which replaces both GBM and EGLStreams (to my knowledge). Why would we want to merge EGLStreams now if its replacement is already being worked on? The amount of maintenance overhead this will introduce for the limited amount of time it'll be useful just doesn't seem worth it.

                  Comment


                  • #59
                    Originally posted by Veerappan View Post
                    Here's what I don't get:

                    Nvidia is already working on a unified device memory allocation API which replaces both GBM and EGLStreams (to my knowledge). Why would we want to merge EGLStreams now if its replacement is already being worked on? The amount of maintenance overhead this will introduce for the limited amount of time it'll be useful just doesn't seem worth it.
                    You're probably underestimating the timescale of the development of this new API. I'm not holding my breath for it to appear soon.

                    Comment


                    • #60
                      Originally posted by starshipeleven View Post
                      You're probably underestimating the timescale of the development of this new API. I'm not holding my breath for it to appear soon.
                      Even if it takes a year or two to materialize (the nvidia guys behind it are using nouveau for their prototype project, which means mesa/nouveau at least might be quick to support it on the OSS side), that's still peanuts in the grand scheme of things.

                      Every day I bang my head on my desk when I go through debugging/troubleshooting of code that was written 15 years ago (and wasn't always well-written to begin with), and it's this long-term maintenance burden that I'd be worried about here.

                      Comment

                      Working...
                      X