Announcement

Collapse
No announcement yet.

NVIDIA Publishes Patches For Its Driver To Work With Wayland's Weston

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

  • #11
    Originally posted by Serafean View Post
    Could someone please explain why Weston needs patching to support the nvidia blob? I thought they already were using EGL...
    Weston uses gbm to manage display buffers, nvidia did not want to provide gbm implementation for their drivers, instead they do that with EGLDevice and EGLStream.

    Comment


    • #12
      Originally posted by Serafean View Post
      Could someone please explain why Weston needs patching to support the nvidia blob? I thought they already were using EGL...
      Because Nvidia doesn't like the standard way to do things, they must always follow the _nv® path. I'm pretty sure another middle finger awaits them at the end of the road.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #13
        Originally posted by magika View Post
        Weston uses gbm to manage display buffers, nvidia did not want to provide gbm implementation for their drivers, instead they do that with EGLDevice and EGLStream.
        Tbh, gbm is tied to Mesa and nvidia's driver never had anything to do with Mesa. So when Weston chose to go gbm/Mesa only, the consciously left nvidia out. And Weston is just the reference implementation of Wayland, other implementations may work just fine with EGLDevice/EGLStream. Of course, doing that, you're actively choosing EGL and leaving out Vulkan. I think it will take a while for things to settle down, everything in this area seems to be under heavy development these days.

        Comment


        • #14
          Originally posted by darkbasic View Post
          Because Nvidia doesn't like the standard way to do things, they must always follow the _nv® path. I'm pretty sure another middle finger awaits them at the end of the road.
          At the end of the day Nvidia does things their way and they get away with it because their drivers consistently leverage the full potential of their hardware. I truely aplaude AMD with their new hybrid driver stack but seeing how the r9 fury performs raises huge red flags for anyone wanting to buy and run a high end AMD card on Linux even if they make the open source purests happy.

          Comment


          • #15
            Originally posted by jmcharron View Post

            At the end of the day Nvidia does things their way and they get away with it because their drivers consistently leverage the full potential of their hardware. I truely aplaude AMD with their new hybrid driver stack but seeing how the r9 fury performs raises huge red flags for anyone wanting to buy and run a high end AMD card on Linux even if they make the open source purests happy.
            GBM is a linux/drm specific bit, nvidia tries to get the same functionality with EGL, something more system-agnostic. I applaud them for that.

            Comment


            • #16
              Originally posted by darkbasic View Post
              Because Nvidia doesn't like the standard way to do things, they must always follow the _nv® path. I'm pretty sure another middle finger awaits them at the end of the road.
              As many fingers as it's needed... this helps... it will hammer their patches until they fit, open-source will win in the end.

              Comment


              • #17
                Originally posted by Licaon View Post
                As many fingers as it's needed... this helps... it will hammer their patches until they fit, open-source will win in the end.
                The normal patch approval process consists in several REVISIONS until the patches gets merged, the Nvidia one uses middle fingers instead xD
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #18
                  Originally posted by bug77 View Post
                  Tbh, gbm is tied to Mesa and nvidia's driver never had anything to do with Mesa. So when Weston chose to go gbm/Mesa only, the consciously left nvidia out. And Weston is just the reference implementation of Wayland, other implementations may work just fine with EGLDevice/EGLStream. Of course, doing that, you're actively choosing EGL and leaving out Vulkan. I think it will take a while for things to settle down, everything in this area seems to be under heavy development these days.
                  GBM is absolutely _not_ tied to Mesa, and has been implemented by other proprietary drivers just fine.

                  Comment


                  • #19
                    Originally posted by mlau View Post
                    GBM is a linux/drm specific bit, nvidia tries to get the same functionality with EGL, something more system-agnostic. I applaud them for that.
                    KMS was a linux/drm specific bit, but that didn't prevent Nvidia from implementing it. Same goes for GBM.

                    Comment


                    • #20
                      Originally posted by mlau View Post
                      GBM is a linux/drm specific bit, nvidia tries to get the same functionality with EGL, something more system-agnostic. I applaud them for that.
                      Also, if you look at Nvidia's introductory post on the mailing list, it contains this:

                      we also needed extended functionality for EGLStreams and EGLOutput consumers provided by following extensions:

                      - EGL_NV_stream_attrib

                      - EGL_EXT_stream_acquire_mode

                      - EGL_NV_output_drm_flip_event


                      I don't know about you, but two _vendor_ extensions don't exactly scream "system-agnostic" to me.

                      Comment

                      Working...
                      X