Announcement

Collapse
No announcement yet.

GNOME Shell & Mutter Up To 3.24 Beta State

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

  • GNOME Shell & Mutter Up To 3.24 Beta State

    Phoronix: GNOME Shell & Mutter Up To 3.24 Beta State

    GNOME Shell 3.23.90 and Mutter 3.23.90 are now available for testing, which represents the component's release for the GNOME 3.24 beta...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I can't help but feel the working going into EGLStreams is taking away from work that's needed to bring Mutter's GBM backend up to feature parity with Weston. Right now it lacks full support for the standard Wayland EGL buffer formats, in particular YUV and especially multi-planar buffers.

    Comment


    • #3
      Originally posted by Griffin View Post
      Gnome just proved this can be done even in a post-wayland world. This feature is nice and useful but the best part is that all the haters were proven WRONG. Again.
      Well, dunno what you mean by proving wrong. is a separated render code with a bunch of glue code to handle surfaces in the same way they would need to do to support Quartz on OS X or even windows.

      The point always has been this would make window managers support 2 separated render pipelines on runtime and that is extra work for nothing special just the fact nVidia found this easier and that hasn't changed at all.

      The optimal solution would be to force nVidia to work on improving GBM with Mesa team and have 1 solid well tested render path for wayland regardless the GPU vendor.

      Remember the mess on DX and GL because nVidia decide to brute force their spec instead of the official spec, so you needed(and in some cases still need) different render path for nVidia and everyone else? because that is what you are getting happy about, nVidia need 1 render path and everyone else another and as history has proven, it doesn't end well for the final user

      Comment


      • #4
        Originally posted by jrch2k8 View Post


        The optimal solution would be to force nVidia to work on improving GBM with Mesa team and have 1 solid well tested render path for wayland regardless the GPU vendor.
        Noone can "force" Nvidia to do anything. Red Hat has implemented this patches with the understanding that this is a transitionary step. Some of this was covered in the many blog posts here -> https://blogs.gnome.org/uraeus/category/gnome/

        Comment


        • #5
          Originally posted by RahulSundaram View Post

          Noone can "force" Nvidia to do anything. Red Hat has implemented this patches with the understanding that this is a transitionary step. Some of this was covered in the many blog posts here -> https://blogs.gnome.org/uraeus/category/gnome/
          true, maybe force was the wrong word(non native speaker here), maybe don't adopt is more accurate for what i meant.

          also true they can simply choose to not support wayland at all but i still believe collaborate improving GBM is a better solution than accept nVidia specific codepaths but i also understand Red Hat is a company and probably an interim solution is required for their customers and those customers pay exactly for those services.

          Comment

          Working...
          X