Announcement

Collapse
No announcement yet.

The Performance Penalty Of Xfce/Xubuntu On XMir

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

  • Originally posted by TAXI View Post
    Did Mark ever say it will run native? Cause they have XMir for other DEs...
    Only for as long as KWin continues to support X. Once it's up and running on native Wayland, I'd give it a year or two before the X support has either bit-rotted, or been deleted outright.

    Comment


    • Originally posted by bwat47 View Post
      There is so much stupidity in this post I don't even have any words. "Throw them out of the FOSS community and not allow them to use linux"

      ..seriously? bunch of fucking 10 year olds in this forum that have no clue what they are talking about.
      You will remember me one day...

      As for apple the billions of profit and millions of iphones speak for themselves.

      Canonical IS a company! Take that as a fact and don't rush to conclusions!

      Companies contribute at something ''Free'' ONLY when they will gain profit out of it! That's it! So simple and stupid if you like!

      Comment


      • Originally posted by intellivision View Post
        However, the BSD license (3 or 2 clause) is both free (as in freedom) as it permits the source code to be used, modified and distributed by everyone and open source.
        The BSD license is permissive, meaning that you don't have to publish your source code under the same license as the original work.
        It's surprising how many people in the OSS community don't get this and immediately think BSD == proprietary, even though it's a FOSS license approved by both the FSF and OSI.
        https://en.wikipedia.org/wiki/BSD_licenses
        the ulgy one is the 4-clause and it is not Opensource the http://en.wikipedia.org/wiki/BSD_licenses#4-clause

        i forgot to point out the Key here "unlikely that we would be able to open source the commercial" so its going to be Proprietary if they go down that road

        Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.

        Comment


        • Originally posted by LinuxGamer View Post
          the ulgy one is the 4-clause and it is not Opensource the http://en.wikipedia.org/wiki/BSD_licenses#4-clause
          The 4 clause BSD license has been deprecated since 1999 in favour of the FSF and OSI approved 3 clause BSD license.
          In fact, it even says as such in the link you provided, and I don't know how much of an idiot you are to overlook that detail but I have a pretty good guess.

          Comment


          • There are and there will never be any performance gains when using entire DEs on XWayland/XMir.

            Comment


            • Originally posted by Mason8DF View Post
              There are and there will never be any performance gains when using entire DEs on XWayland/XMir.
              Correct, but once everything is ironed out with xmir the performance should theoretically be pretty much identical. The reason it is currently slower is because several major issues with xmir have not been fixed yet, but they are being worked on: http://blog.cooperteam.net/2013/07/x...rformance.html

              Or: Why XMir is slower than X, and how we'll fix it

              We've had a bunch of testing of XMir now; plenty of bugs, and plenty of missing functionality.

              One of the bugs that people have noticed is a 10-20% performance drop over raw X. This is really several bits of missing functionality - we're doing a lot more work than we need to be. Oddly enough, people have also been mentioning that it feels "smoother" - which might be placebo, or unrelated updates, or might be to do with something in the Mir/XMir stack. It's hard to tell; it's hard to measure "smoother". We're not faster, but faster is not the same as smoother.

              Currently we do a lot of work in submitting rendering from an X client to the screen, most of which we can make unnecessary.
              The simple bit

              The simple part is composite bypass support for Mir - most of the time unity-system-compositor does not need to do any compositing - there's just a single full-screen XMir window, and Mir just needs to flip that to the display. This is in progress. This cuts out an unnecessary fullscreen blit.
              The complicated part is in XMir itself

              The fundamental problem is the mismatch between rendering models - X wants the contents of buffers to be persistent; Mir has a GLish new-buffer-each-frame. This means each time XMir gets a new buffer from Mir it needs to blit the previous frame on first, and can't simply render straight to Mir's buffer. Now, we can (but don't yet) reduce the size of this blit by tracking what's changed since XMir last saw the buffer - and a lot of the time that's going to be a lot smaller than fullscreen - but there's still some overhead?.

              Fortunately, there's an way around this. GLX matches Mir's buffer semantics nicely - each time a client SwapBuffers it gets a shiny new backbuffer to render into. So, rather like Compiz's unredirect-fullscreen-windows option, if we've got a fullscreen? GLX window we can hand the buffer received from Mir directly to the client and avoid the copy.

              Even better, this doesn't apply only to fullscreen games - GNOME Shell, KWin, and Unity are all fullscreen GLX applications.

              As always, there are interesting complications - applications can draw on their GL window with X calls, and applications can try to be fancy and only update a part of their frontbuffer rather than calling SwapBuffers; in either case we can't bypass. Unity does neither, but Shell and KWin might.
              Enter the cursor

              In addition to the two unnecessary fullscreen blits - X root window to Mir buffer, Mir buffer to framebuffer - XMir currently uses X's software cursor code. This causes two problems. Firstly, it means we're doing X11 drawing on top of whatever's underneath, so we can't do the SwapBuffers trick. Secondly, it causes a software fallback whenever you move the cursor, making the driver download the root window into CPU accessible memory, do some CPU twiddling, and then upload again to GPU memory. This is bad, but not terrible, for Intel chips where the GPU and CPU share the same memory but with different caches and layouts. It's terrible for cards with discrete memory. Both these problems go away once we support setting the HW cursor image in Mir.

              Once those three pieces land there shouldn't be a meaningful performance difference between XMir-on-Mir and X-on-the-hardware.
              Last edited by bwat47; 07 August 2013, 10:38 PM.

              Comment


              • Originally posted by Delgarde View Post
                Only for as long as KWin continues to support X. Once it's up and running on native Wayland, I'd give it a year or two before the X support has either bit-rotted, or been deleted outright.
                Very doubtful. They still have an XRender backend and support turning off compositing altogether - KWin usually supports old technologies for quite a while after the newer ones come out.

                Comment

                Working...
                X