Announcement

Collapse
No announcement yet.

The First Benchmarks Of Unity On XMir: There's A Performance Hit

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

  • #91
    Just to clear up a bit about licenses and copyright.

    Copyright is akin to property rights. If you have the copyright to a piece of work, you own the work. You can do whatever you want with it. License it in one way or another, etc...
    In the case of Canonical Copyright assignment, for every contribution:
    - the author of the contribution keeps full copyright over his work. He can, for example, license it differently to some other project at any time (until he dies or copyright expires, at which points it becomes public domain).
    - Canonical gains conditional, shared copyright over the contribution.

    License is a set of rights given by a copyright owner, to a given individual or group of person. Theses rights mostly concern use, modification, redistribution, merchantability, etc..
    The copyright owner can provide multiple licenses to multiple overlapping groups. If a user has multiple licenses for the use of a given work, he can choose any license he wants, and is not bound by the licenses he is not using.
    => A company that has access to the code through the GPL license and a (payed for) non-transferable permissive license is not bound by the GPL.

    Licenses (as opposed to contracts) are revokable. It is not known if the OSS licenses (GPL, MIT, BSD, etc...) can be revoked, as it has never been tried in court (almost happened, once, but they settled before judgement). Maybe yes, maybe not. Probably not easily, and not everywhere, and well, nobody managed it yet.
    By any means, you would need all the copyright holders to revoke the license (and a court to find that legal) to completely close a project.
    In the case of Canonical, it means the original contributor must do the same.
    But actually, as Canonical promises in a contract to license the contribution with its original licenses (the licenses they were using at the time of submission), it actually means that even if the contributor tried to revoke it, Canonical couldn't.

    So, what can be done by canonical:
    - license a contribution as closed-source, modify the contribution without licensing the modifications under GPL. Basically, fork the contribution under closed-source. The contributor can do the same, but only for his work, not the full
    what cannot be done:
    - revoke GPL license to the contribution, ie retroactively close source the entire project. There is a yet untested risk that they could retroactively close their own code, but that's not Canonical specific.

    Comment


    • #92
      Originally posted by GreatEmerald View Post
      Hmm, does XMir/XWayland start just one X server, or one X server per app? Or can it do it both ways?
      The aim is to have one X server per app that requires X (hence the potential better performance of xMir/xWayland + MirWayland over X.org, because each app just fullscreens into its own X server, which reduces the work and roundtrips done by these servers).
      The videos here are one XMir server with a full compositor in it, so all apps in a compositor in a XMir X server in a Mir server (hence the not so good performance).

      Comment


      • #93
        Originally posted by mrugiero View Post
        Right, I skimmed it the last time I reread it to check if I was just misreading when everyone said Mir would be 'at the earliest' in 14.04. It clearly says, tho, Mir (through XMir) will be used by default in 13.10, without X.org server fallback in 14.04. Also, this strengthens my point that Unity will actually run in real life on XMir, not only in 13.10, but in the LTS 14.04.
        And the really sad part is, Xmir (Aka Xwayland) was not made to run DE's, Major Fail on Canonical's Part putting it into an LTS, it's just going to end up bad for Ubuntu users all around, Canonical need's to put down the pipe, if it fuck's up an LTS it is going to look really bad on them, why use Xmir over Xorg? you take a lost in performance's, add bug's etc.

        Comment


        • #94
          Originally posted by spacetoilet View Post
          And the really sad part is, Xmir (Aka Xwayland) was not made to run DE's, Major Fail on Canonical's Part putting it into an LTS, it's just going to end up bad for Ubuntu users all around, Canonical need's to put down the pipe, if it fuck's up an LTS it is going to look really bad on them, why use Xmir over Xorg? you take a lost in performance's, add bug's etc.
          I think so, too, that's why I kind of assumed the plan of running Unity 8 there was still on. I agree, liking or disliking Unity or Mir, switch this way is a bad decision. They make the LTS use Mir without any benefits, and with likely performance drawbacks. It would make a lot more sense, if they want to test Mir with 13.10, to go back to the usual X.org for LTS and then switch to Unity 8 and Mir in 14.10.

          Comment


          • #95
            Originally posted by dee.
            You should probably check on that fanaticism of yours. When you start wishing for others to die due to differences in opinion, you're treading on dangerous ground. Pretty soon, you'll end up in a warehouse somewhere, drinking juice laced with potassium cyanide because your glorious leader promises eternal life on a faraway planet where all computers run Mir...
            you know what the best part is

            Jono Bacon @ Martin Gr??lin we haven't said that KWin works on Mir, we have said that it works on XMir on Mir. This is not a falsity, it does work. I feel we have been pretty clear that it is XMir and not Mir.
            Ingolf Sch?fer @ Jono Bacon "I’ve absolutely no doubt that Kwin will work just fine on top of Mir. And I’m pretty confident Mir will be on a lot more devices than Wayland. Which would be good for KDE and Kubuntu and Plasma Active." said by Mark Shuttleworth himself in this blog post: http://www.markshuttleworth.com/archives/1235
            Last edited by spacetoilet; 28 June 2013, 07:35 PM. Reason: 404?

            Comment


            • #96
              Valve's first tries got 3 FPS.

              Seeing the results there's some serious CPU overhead that probably will be removed in the future.

              Comment


              • #97
                spacetoilet, mrugiero, dee., please don't feed the troll. Just click the Report Post "!" link at the bottom left of the post. Relevant posts deleted.

                Comment


                • #98
                  Originally posted by dh04000 View Post
                  If an application loses 30% of performace, that comes no were near 1 secon (1000ms) lag.
                  Pretty true, people is exaggerating things up. As some one else said FPS means frames per second, so a 1 second lag means 1 frame per second.

                  Originally posted by mrugiero View Post
                  The people who says XWayland will be faster than plain X means using it for apps. Running a desktop implies a lot more work on the X.org server inside that you can ignore otherwise. You are having window management, compositing, etc, inside the X.org server. When you use it for an app, the app inside the server will behave (if I get it right) somewhat as a fullscreen window in a non-compositing environment, and all the real management will happen outside the X.org server, being done by either Wayland or Mir. So you avoid lots of operations. Of course a whole desktop running on XWayland will be slower than at least a native desktop on Wayland, and almost certainly than a desktop on X.
                  And the same way XWayland could be faster than X for particular apps it's likely that, assuming Mir will be faster than X, XMir will be faster than X for particular apps. Whole desktops are out of scope for XMir and XWayland for common sense. There is no reason to not use X if you are going to use an X desktop, since you will be unable to load Mir or Wayland apps.
                  I understand that running a desktop environment on top of xmir/xwayland is just a waste of resources, but I still don't understand the technical details behind saying that running just applications under xwayland/xmir will result in faster rendering for X applications than running them in X directly.

                  Anyway it seems that canonical gave a shot at running a full DE to keep the development adrenaline going on or shut the people at kubuntu saying that ubuntu and kubuntu flavors would not be able to co-exists due to mir.

                  Edit:
                  Interesting:


                  One of the reasons for this result set is missing composite bypassing support, which we are aware of since January. Composite bypass helps when apps/benchmarks run fullscreen because… well, because they don’t need to be composited. Gamers out there… there is hope and a plan in place to get you your precious FPS back. This feature/bug is currently scheduled once other key functionality landed. Also, in order to make FPS based benchmarks really count, we need eglSwapInterval(0) implemented, which is currently in progress
                  Last edited by TheOne; 28 June 2013, 09:22 PM.

                  Comment


                  • #99
                    Originally posted by erendorn View Post
                    Just to clear up a bit about licenses and copyright.

                    Copyright is akin to property rights. If you have the copyright to a piece of work, you own the work. You can do whatever you want with it. License it in one way or another, etc...
                    In the case of Canonical Copyright assignment, for every contribution:
                    - the author of the contribution keeps full copyright over his work. He can, for example, license it differently to some other project at any time (until he dies or copyright expires, at which points it becomes public domain).
                    - Canonical gains conditional, shared copyright over the contribution.

                    License is a set of rights given by a copyright owner, to a given individual or group of person. Theses rights mostly concern use, modification, redistribution, merchantability, etc..
                    The copyright owner can provide multiple licenses to multiple overlapping groups. If a user has multiple licenses for the use of a given work, he can choose any license he wants, and is not bound by the licenses he is not using.
                    => A company that has access to the code through the GPL license and a (payed for) non-transferable permissive license is not bound by the GPL.

                    Licenses (as opposed to contracts) are revokable. It is not known if the OSS licenses (GPL, MIT, BSD, etc...) can be revoked, as it has never been tried in court (almost happened, once, but they settled before judgement). Maybe yes, maybe not. Probably not easily, and not everywhere, and well, nobody managed it yet.
                    By any means, you would need all the copyright holders to revoke the license (and a court to find that legal) to completely close a project.
                    In the case of Canonical, it means the original contributor must do the same.
                    But actually, as Canonical promises in a contract to license the contribution with its original licenses (the licenses they were using at the time of submission), it actually means that even if the contributor tried to revoke it, Canonical couldn't.

                    So, what can be done by canonical:
                    - license a contribution as closed-source, modify the contribution without licensing the modifications under GPL. Basically, fork the contribution under closed-source. The contributor can do the same, but only for his work, not the full
                    what cannot be done:
                    - revoke GPL license to the contribution, ie retroactively close source the entire project. There is a yet untested risk that they could retroactively close their own code, but that's not Canonical specific.
                    It sounds like you have more of an issue with copyright assignment than the license itself.
                    While I admit CA isn't the best solution, it does assist a project to change licenses if they feel the desire to.
                    For instance, VLC had to remove code from libvlc since they wanted to relicense it as LGPL, but they couldn't contact a contributor who's code was under the GPL.
                    They eventually changed the license, but the process took months to do. And some projects are so large, such as Linux and Wordpress, that even if desired the license cannot be changed.
                    And Canonical isn't the only organisation that does this. OwnCloud, Cunity, Diaspora*, Apache and software from the FSF all require CA's or your contribution has to be under a permissive license such as MIT for specifically the issue of license changes.
                    And I'm sure that with CA you don't relinquish your rights over your code, you just give a copy of your rights to someone else.
                    To use a proprietary Mir as an example, there would be nothing stopping you from banding together with the other Mir developers, pooling your code together and creating a FOSS competitor.

                    Comment


                    • Originally posted by TheOne View Post
                      Pretty true, people is exaggerating things up. As some one else said FPS means frames per second, so a 1 second lag means 1 frame per second.
                      First, I must say I didn't watch whatever video you are meaning, so I don't get misunderstood.
                      However, in a post which was deleted (because it was an answer to some troll), I explained something. In the post where it's stated there is one second lag, first it explicitly said *at times*. Also, when you talk about lag you don't imply it's at all the time, because then it's just a low general performance.
                      There might be a one second lag (and I say might because I didn't watch the video, i.e. I don't know if there is) and not be reflected by the benchmark, which makes a statistic of a given runtime. It measures some statistically relevant data which doesn't seem to include the range of obtained FPS. If I read it correctly, it only measures median, average and standard deviation, while lag is in most cases an outlier, something that happens during a short amount of time. If this is the case, this generally high performance (I think considering it's running on a compatibility layer, 10-15% loss is not really a bad performance, it's just bad because of the fact it's unneeded) might actually seem lower to the benchmark because of this short periods of extremely low performance. Furthermore, this seemingly bad news for XMir might be better than they look, because this probably points the issue to be a single bottleneck or bug, instead of being something more spread around in the code.

                      I understand that running a desktop environment on top of xmir/xwayland is just a waste of resources, but I still don't understand the technical details behind saying that running just applications under xwayland/xmir will result in faster rendering for X applications than running them in X directly.

                      Anyway it seems that canonical gave a shot at running a full DE to keep the development adrenaline going on or shut the people at kubuntu saying that ubuntu and kubuntu flavors would not be able to co-exists due to mir.
                      Well, don't take what I say as a sure thing, because I lack a lot of knowledge in this area, and I don't know how the current implementation is done, so I will just say how I think it might be better.
                      First, we should assume that either Wayland or Mir (whichever we care about) is faster than X.org, at the very least on compositing.
                      Then, we can think the virtual server will only activate compositing if there is an app calling the extension, which will be probably a window manager. If not, all the compositing will be managed by the system compositor or whatever it's called on Mir, which is more efficient than X. This X will not need to actually handle most of the input either, since inside the surface, where the rootless X server is running, you have all the input and all the (virtual) screen on your app. This means you can safely ignore, if no WM is loaded inside this (which might probably be figured out in several ways, where one valid for compositing window managers might be the loading or not of compositing extension), all of the input grab and release requests. For all that X.org cares about, this windows is the only thing that will handle any input. Since compositing is off, the only thing the X server will care about in terms of output will be what the client window wants to draw. And I guess there are several other parts which could be easily ignored with this assumption of a single, fullscreen app for X11. It's like taking shortcuts, mostly.

                      EDIT: I forgot to say, the other thing about running on top of a compatibility layer is that, as any code, might introduce bugs. It's usually a trade-off for a potential benefit (in the case of using XMir/Wayland in a native Mir/Wayland system, the obvious benefit is that you are able to run software that has not been ported), but in this case there is no benefit, and it makes it harder to maintain. If XMir or XWayland introduces new bugs on KWin, they will not fix them, which makes sense because even reproducing them takes a lot of work if they don't use that solution, and it's very distro specific (at least at the moment; KWin runs natively on Wayland, so there's REALLY no point on trying that configuration, aside for love for science, and Mir is currently Ubuntu only). Kubuntu maintainer says he (and that flavor's community) lacks the know-how and the manpower to fix bugs in KWin, so they can't fix what doesn't correspond to upstream. This means that chances are there will be no one to fix XMir/KWin combination bugs, except Canonical pays someone to. And also, this patches wouldn't be accepted upstream, because of several reasons, one of which is that new code is always likely to introduce new bugs. However, this might be the only viable option: using other solution would mean having multiple duplicated libs (at the very least, the toolkits), which would have to be maintained and tested, too.
                      Also, at some point is likely X.org versions get dropped from upstream, tho I wouldn't expect that to happen in the next two or three years, and this means this solution will be ineffective, or Kubuntu will have to bring outdated versions.
                      Last edited by mrugiero; 28 June 2013, 10:11 PM.

                      Comment

                      Working...
                      X