Announcement

Collapse
No announcement yet.

Running The Latest GNOME Wayland Shell On Fedora 20

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

  • #11
    Originally posted by Ericg View Post
    Eeeeeeeeeh... SDL2--- TWO -- has been ported to Wayland. Not SDL1. So we need some apps that are written against SDL2 in order to actually test them accurately.
    Considering how long SDL2 has been in development, the games' programmers had plenty of time to port to it. I'd be surprised if no game is there yet (at least in some dev branch).

    Comment


    • #12
      Porting a game to use the Wayland-capable SDL shouldn't be too difficult. Let's see what's on the horizon- I wonder if SDL can change the backend at runtime (like GTK), or if you need to have either an X11 package or Wayland package.

      Comment


      • #13
        Originally posted by Andrecorreia View Post
        i care, if a game work with 60 fps on x and a 30 on wayland...! and like inittial with xmir we have a noticiable regression on fps
        the xwayland performances are 80% of performance in X, not bad after all, xwayland is young and there is room for performance improvement expecialy if you port the game wayland.

        Comment


        • #14
          Originally posted by edoantonioco View Post
          It should be compared with Mir. That would be interesting
          Erhm, no. XWayland, what is tested here, should be compared with XMir. As it stands, both have an overhead penalty over native X.org.

          When both native Mir and native Wayland software appears (and hopefully that software runs on both), Mir should be compared to Wayland.

          Comparing a compatibility layer with a native display stack is apples and oranges.

          Comment


          • #15
            There is something strange with these benchmarks. I imagine that some driver optimization or something else is perturbing the results.

            For example the last test has 57.86 fps on X, and 50.38 fps on Fedora XWayland + Gnome.
            This looks strange, because in theory, the main different should be an additional copy in XWayland case, and it shouldn't be more than 2-3 fps here.

            And a similar test I did makes me think it is a driver optimization.

            I have tested XWayland vs XWayland + AsyncSwap (avoid the additional copy) on my dedicated card (Amd hd 7730m) on an embedded compositor running under Prime (compositor copy + XWayland copy / no XWayland copy (if AsyncSwap)).


            Each time I restart the computer between the tests.

            It gives:

            Reaction Quake 3 1.0 Beta - pts/reaction-1.0.4 (Resolution 1920x1080)

            Embedded Weston compositor + AsyncSwap:
            Code:
            Test Results:
                    53.2
                    53.3
                    53.8
            
                Average: 53.43 Frames Per Second
                Minimum: 53.2
                Maximum: 53.8
            Without AsyncSwap:

            Code:
            Test Results:
                    49.8
                    50
                    42
                    41.7
                    41.4
                    41.6
            
                Average: 44.42 Frames Per Second
                Minimum: 41.4
                Maximum: 50
            On X (with Prime):

            Code:
            Test Results:
                    52,1
                    42,1
                    43,9
                    44
                    43,9
                    44
            
                Average: 45,17 Frames Per Second
                Minimum: 43,1
                Maximum: 52,1
            So after a few time, with two copies instead of one (embedded Weston + AsyncSwap / bare X with Prime), there is a high fps drop after the benchmark run for a few minutes.

            Since here we compare two copies(Gnome (no compositing bypass) + XWayland) vs one (bare X (no prime)), I can't held imagine we see a similar optimization issue here (even if Michael benchmarks are on an intel card and not an AMD card as I tested)

            Comment


            • #16
              1280 MBs of RAM? What is this, 2001? 12.8 GB would be a bit more "normal" wouldn't it?

              Comment


              • #17
                Looking to the git branches (Mutter, GDM, etc.) I don't see many commits in the last weeks (especially on wayland side), so I didn't aspect many differences from the previous test.

                Comment


                • #18
                  Could somebody explain to me why individual applications need to be ported to Wayland?
                  I thought applications use things like QT and GTK or OpenGL and SDL?
                  Isn't it the toolkits and OpenGL/SDL that just need to be ported? (Is OpenGL in mesa? SDL?)

                  Comment


                  • #19
                    Originally posted by RoboJ1M View Post
                    Could somebody explain to me why individual applications need to be ported to Wayland?
                    I thought applications use things like QT and GTK or OpenGL and SDL?
                    Isn't it the toolkits and OpenGL/SDL that just need to be ported? (Is OpenGL in mesa? SDL?)
                    Because of hidden X dependencies.
                    If in the application A you call something from GLX or other X related code, then you need to port that code away from X before run nicely on Wayland.
                    If you have not hidden X dependencies then yes, a ported toolkit should be enough.
                    Last edited by valeriodean; 10-29-2013, 10:19 AM. Reason: typo

                    Comment


                    • #20
                      Originally posted by r_a_trip View Post
                      Erhm, no. XWayland, what is tested here, should be compared with XMir. As it stands, both have an overhead penalty over native X.org.

                      When both native Mir and native Wayland software appears (and hopefully that software runs on both), Mir should be compared to Wayland.

                      Comparing a compatibility layer with a native display stack is apples and oranges.
                      So, XWayland should be compared against XMir, I would like to see that.

                      Comment

                      Working...
                      X