Announcement

Collapse
No announcement yet.

The First Wayland Benchmarks From Fedora 20 Show Great Promise

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

  • #41
    Originally posted by edoantonioco View Post
    I just hope than wayland support will be as easy as a simple new feature in an update of the game, and not to port the games almost from 0 again to be able to play it in wayland, in that case, valve would not be happy, because all their work is in the currently state of linux (and the same for the other people than had ported games to linux).
    As far as I am aware this should mostly be handled by the abstraction layers being used, such as SDL.

    Comment


    • #42
      the difference being this is barely usable, even OP stated that it crashed and it was hell to get it to work


      for Xmir I can't say I had a single crash or show stopping bug

      Comment


      • #43
        Originally posted by Pallidus View Post
        the difference being this is barely usable, even OP stated that it crashed and it was hell to get it to work


        for Xmir I can't say I had a single crash or show stopping bug
        But then, you hadn't a Mir shell and compositor either, so what's the point?

        Comment


        • #44
          The reasons to replace Xorg are well know, listed here.
          Some months yet and I will use a well done display server.

          Comment


          • #45
            As an additional comment, we found that Weston causes a useless copy (X compositing) because the X decoration window it uses for X application has different visual than the application. That means X has to do an additional copy. (That's going to be fixed)

            After looking closer at the figures, the performance hit of Gnome XWayland is not due to a similar issue. It isn't an overhead for every frame, but a constant overhead per second.
            drago01 comments tells that Gnome doesn't support yet bypassing Wayland compositing. It makes sense to say the performance hit observed is entirely due to this: all benchmarks run >= 60 fps, causing Wayland to composite 60 times per second (= constant overhead).

            Currently work is done to support vsync in XWayland (almost done), and (harder) respect the Wayland buffer release semantic, in the cases in which we can do it without impacting performance, to suppress tearings.
            It is also possible that performance increases if we manage to implement a DDX feature proposed by Chris Wilson a few years ago, implemented in the intel DDX, but whose patch to use the feature has not been merged in X yet (but maybe it will be merged with XWayland, who knows?).
            Last edited by mannerov; 12 October 2013, 08:18 AM.

            Comment

            Working...
            X