Page 13 of 13 FirstFirst ... 3111213
Results 121 to 127 of 127

Thread: The Performance Penalty Of Xfce/Xubuntu On XMir

  1. #121
    Join Date
    Apr 2010
    Posts
    794

    Default

    Quote 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.

  2. #122
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    255

    Default

    Quote 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!

  3. #123
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Quote 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

    http://phoronix.com/forums/showthrea...for-commercial

  4. #124
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote 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.

  5. #125
    Join Date
    Aug 2013
    Posts
    8

    Default

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

  6. #126
    Join Date
    May 2010
    Posts
    684

    Default

    Quote 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; 08-07-2013 at 11:38 PM.

  7. #127
    Join Date
    Oct 2008
    Posts
    3,212

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •