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

  • #41
    If someone will maintain it, is not the point, is the project/patch encapsulation so bad that it can't be add without producing a management hell?

    Comment


    • #42
      Originally posted by Brisse View Post

      One tries hard to lock you in on purpose. The other doesn't.
      On purpose? You mean all these guys dreaming to forbid anybody to "capitulate" to nvidia by implementing EGLStreams support? CUDA was a first GPGPU framework, you can't blame NVidia for inventing their solution instead of OpenCL because there wasn't OpenCL at that time. And you can't blame NVidia for still supporting CUDA.
      Also, in a few years we are probably going to see a third vendor enter the high end GPU market and they sure won't support Nvidia proprietary technology.
      That depends. Once Intel was planning to return to GPU market with the Larrabee project, which was designed as multicore x86. So, Intel doesn't mind to have patented proprietary solution instead of open one.

      Comment


      • #43
        Originally posted by starshipeleven View Post
        FYI:
        GBM is for display, CUDA is for computing, great apples and oranges comparison.
        And one starts with "G" while other with "C". When you don't like analogy, you always find apples and oranges.

        Originally posted by starshipeleven View Post
        Were you afraid of talking about our lord and saviour OpenCL?

        And even then, GBM is not proprietary and patented, any vendor can use it.
        EGLStreams isn't patented too, you can add this extension to mesa stack and then will have one and only way to allocate buffers within wayland compositors. Actually, it is much easier to add one another EGL extension than rewrite nvidia blob.
        Originally posted by starshipeleven View Post
        CUDA is, and whoever tries to offer CUDA on their hardware will get sued to hell by NVIDIA.
        NVidia supports OpenCL too, anyone who wishes can use openCL and have no vendor lock. So, why do you blame NVidia? They guilty because they didn't drop CUDA when OpenCL was created? Or because they haven't give their CUDA to a competitor?

        Comment


        • #44
          Originally posted by Khrundel View Post
          And one starts with "G" while other with "C". When you don't like analogy, you always find apples and oranges.
          Does not justify making nonsense analogies to begin with.

          EGLStreams isn't patented too,
          This is what you should have compared GBM with, you dumb trollfail.

          But no, you chose to compare GBM to CUDA that is a completely different thing on all levels.

          NVidia supports OpenCL too, anyone who wishes can use openCL and have no vendor lock. So, why do you blame NVidia?
          Is stating facts like "CUDA is proprietary" and "NVIDIA will sue to hell anyone infringing their proprietary stuff" blaming NVIDIA now?


          Comment


          • #45
            Originally posted by kaprikawn View Post

            I'm suggesting [Devuan] should be forced to [use systemd by default] . . . if you're [a Devuan] user who [doesn’t want to use systemd by default] then sucks to be you.. *
            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.

            Comment


            • #46
              Originally posted by RomuloP View Post
              If someone will maintain it, is not the point, is the project/patch encapsulation so bad that it can't be add without producing a management hell?
              The linux kernel is monolithic precisely to prevent the kind of modularity Windows and UEFI provide that encourages closed-source. The fact APIs take collaboration in design and maintenance isn't a bug. It's a feature.

              Comment


              • #47
                Originally posted by c117152 View Post

                The linux kernel is monolithic precisely to prevent the kind of modularity Windows and UEFI provide that encourages closed-source. The fact APIs take collaboration in design and maintenance isn't a bug. It's a feature.
                And this is my point, why don't it support protocols in terms of modules or any encapsulation that 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". Im perfectly fine with the way Kernel work, I can add a module without community freaking out around the philosophical implications of it and making it a no go. Or even being obligated to get so much in terms to get space in a repository...
                Last edited by RomuloP; 11 April 2018, 09:36 PM.

                Comment


                • #48
                  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.
                  Exactly. Sometimes community is just bipolar...

                  Comment


                  • #49
                    Perhaps Khronos should define a standard for "device memory allocation" and make it part of OpenGL 4.7 and Vulkan 1.2.

                    Comment


                    • #50
                      Isn't GBM part of Mesa? Which makes it somewhat a vendor implementation, so what means its automatically better than nVidia's EGLStreams?

                      Comment

                      Working...
                      X