Announcement

Collapse
No announcement yet.

2D Performance Is Improving For Ubuntu 13.10 XMir

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

  • phoronix
    started a topic 2D Performance Is Improving For Ubuntu 13.10 XMir

    2D Performance Is Improving For Ubuntu 13.10 XMir

    Phoronix: 2D Performance Is Improving For Ubuntu 13.10 XMir

    While the OpenGL gaming performance on XMir/Mir was recently made faster thanks to composite bypass support being committed, the feature doesn't help out non-full-screen applications for rendering faster. To see where the current 2D Linux desktop performance is on Ubuntu 13.10 when using Intel graphics and enabling XMir and the Unity System Compositor, here are some new benchmarks...

    http://www.phoronix.com/vr.php?view=MTQ1ODI

  • Pajn
    replied
    I can't find that statement right now but I think I read it here on Phoronix.
    However it doesn?t really matter, be that XFCE or be that something else.
    What matters is the point, you could use Mir as a system compositor while
    you continue to run you X based DE. Sure most people doesn't wont that
    but I guess at least some does. If I used a DE that were going to stay on
    X I could take that minimal performance hit (that I probably wouldn't notice)
    just to get a nice experience right from the boot.

    That makes it not pointless or stupid. It's a new option that people may
    choose. Is it that bad?

    Notice I'm not saying that everybody nor even most people should do so,
    I'm just saying that some may want, cant they be free to choose so
    themselves?

    Originally posted by ickle View Post
    One of the tasks I am working on is improving the tools we have for analysing power consumption. For one of our big challenges we have is making sure the GPU is running at the right speed at the right time (i.e. turned off for as long as possible, yet still able to deliver those first few frames without a hiccup). As you can probably imagine, the highly irregular nature of a composited 2D workload is harder to get right than a game where we never have enough power... And yet more people are likely to notice the delay when moving windows or the jitter in some wobbly window animation. (And those extra stages in the render pipeline between the application and the user make that challenge so much more fun!) This is yet another reason why consistent latency matters so much more than throughput for user experience.
    Interesting!
    May I ask where you work?

    Originally posted by mrugiero View Post
    That's false at so many levels. Competition *may* be good, and it also may be awfully bad. You push deadlines, release half assed products, how that can be good for anyone?
    I must disagree. I one part "release half assed products" that's the fault
    of that part, not on the competition.
    You are always fully responsible for your own acts, with or without a
    competitor. Don't you think?

    Leave a comment:


  • TheOne
    replied
    Originally posted by mrugiero View Post
    ...
    The window manager, a core part of any DE, talks directly to the X server. Porting to a different toolkit doesn't change this (I heard Qt5 is an exception to this, but I'm not really sure), and it means you need to explicitly port it to Wayland.
    ...
    I thought about that after posting, thanks for the correction.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by nadro View Post
    You can talk directly to Mir even if fullscreen XMir session is active. What about fullscreen games? Remember about events. XEvent system isn't too fast, so here some performance improvements may come, anyway simple SwapBuffer should be little more efficient too in Mir and in Wayland than in X.
    I must say, I forgot about input, REALLY bad. On SwapBuffers, again, even if it's slightly more efficient, that's not a main bottleneck, so any improvement on that side will probably be negligible.
    On the point about talking directly to Mir, what I mean is that you will be unable to use it from inside the X session. You could use it, but then you'd be fully restricted to using it fullscreen.

    BTW. This disscustion Mir vs. Wayland at now is really fun. Both Display Servers are really similar from game developer point of view, so write two different backends aren't a problem. If Canonical want own DS who care? Welcome in open source world, where everyone can do what they want.
    You know, the fact they can doesn't make caring and discussing any less valid. They can do whatever they want, and they are doing it. This doesn't mean I can't criticize them if I think what they do is wrong.
    And writing two different backends IS a problem. Extra work means extra money, which means it's harder to meet the expected costs/benefits ratio a company would expect before porting anything.

    I'm happy that X will be replaced soon by modern DS. Both Mir and Wayland teams did great job for Linux world. Competition always improve level of software. If someone have that many problems with Mir look what Intel did with OpenCL, this the same situation.
    That's false at so many levels. Competition *may* be good, and it also may be awfully bad. You push deadlines, release half assed products, how that can be good for anyone?
    Also, Intel's own OpenCL implementation (which I already criticized in the appropriate thread, mind you) is a whole different thing than Mir, since software written for OpenCL should run on Intel's implementation as well as in Gallium. This means, their fragmentation is localized: it only means they aren't sharing the workload with Gallium. In the case of Mir versus Wayland, you need to write software for Mir or for Wayland. In the common case, this only means porting toolkits to an extra platform. In less common cases, this means writing two backends or supporting only a fraction of the Linux desktop. This is the same problem we have with toolkits.

    Originally posted by Pajn View Post
    Wayland and Mir hopes to finally give us a flicker-free boot experience.
    Some DEs wont get ported to Wayland or Mir (XFCE for example have said they will stick to X).
    So if you want to use XFCE with a flicker-free boot experience you will have to use Mir as a system compositor, compositing the boot and the login manager and then run XFCE in XMir.
    Sacrificing performance through the whole session just to get flicker-free boot is a waste, IMO.

    Originally posted by TheOne View Post
    that means they will have wayland support out of the box
    No, it doesn't. The window manager, a core part of any DE, talks directly to the X server. Porting to a different toolkit doesn't change this (I heard Qt5 is an exception to this, but I'm not really sure), and it means you need to explicitly port it to Wayland.
    XFCE said that for now they'll stick to X, they never stated something like "we will never use either Mir or Wayland". I think it's the sane decision for their limited workforce, to wait until the ones with most people do the hard bits and to have a somewhat easier porting. In the end, I'd expect them to use Wayland.
    Also, I wouldn't sacrifice the whole use performance just for flicker-free boot. It's a personal choice, but I think it's the wrong one.

    Also I like the idea of full compatibility. Either it's a game, a program or a DE it's nice to be able to run in in the compatibility layer. I think the golden goal is that anything that runs in X shall be able to run in XMir or XWayland without any changes.
    That's pointless. If you are going to use an X DE, being unable to run in a correctly integrated way anything non-X-ish, then you are better off just running X.
    I mean, having options and legacy compatibility is alright, but if you are actually making no use of the modern features, you are just wasting cycles in a middleware that does nothing. You keep dragging behind you all of the crufty problems of X.
    Last edited by mrugiero; 09-11-2013, 11:58 AM.

    Leave a comment:


  • TheOne
    replied
    Originally posted by TheBlackCat View Post
    How is it "superior" to be running a rooted X inside Mir/Wayland? It is not that this sort of thing would be fundamentally impossible in XWayland, it is just that nobody implemented it because they didn't see any reason to. So what is the advantage of running rooted X inside XMir/XWayland?
    I haven't said there is some end user advantage (that would be said by a fanboy ), but there may be a development advantage that would help on improving XMir, but as mrugiero has said, there are some optimizations that apply to XMir with a root X and that doesn't apply on a rootless environment, so again, end results may change when running XMir rootless.

    Originally posted by Vim_User View Post
    Any link to that statement?
    Actually XFCE is being slowly ported to GTK3 so that means they will have wayland support out of the box

    Link: http://wiki.xfce.org/releng/4.12/roadmap/gtk3

    Leave a comment:


  • Vim_User
    replied
    Originally posted by Pajn View Post
    Some DEs wont get ported to Wayland or Mir (XFCE for example have said they will stick to X).
    Any link to that statement?

    Leave a comment:


  • ickle
    replied
    Originally posted by Pajn View Post
    Thank you for a informative and interesting post!

    If I get you correct, what this basically means is that this kind of benchmarks
    doesn't rely mean anything. The differences are too small and the "background
    noise" are to high. Is that correct?

    If so, I guess that would mean that this 10% extra overhead aren?t noticeable in
    real usage as the "background noise" can be much higher than the slowdown itself.
    That's correct. One of the big changes noticeable with the UXA to SNA transition is that we go from being driver-limited to application-limited. The most obvious example here is firefox. The biggest way we can futher improve firefox is to reduce the drawing overhead in the application (and the js/xul overheads, but that is a different topic!).

    Originally posted by Pajn View Post
    IIf so that's pretty great, sure it's still a slowdown however that's what expected.

    What would be more interesting than performance benchmarks would be power
    consumption. Where a small performance degradation isn't noticeable even the
    smallest extra power consumption is when running on battery.
    One of the tasks I am working on is improving the tools we have for analysing power consumption. For one of our big challenges we have is making sure the GPU is running at the right speed at the right time (i.e. turned off for as long as possible, yet still able to deliver those first few frames without a hiccup). As you can probably imagine, the highly irregular nature of a composited 2D workload is harder to get right than a game where we never have enough power... And yet more people are likely to notice the delay when moving windows or the jitter in some wobbly window animation. (And those extra stages in the render pipeline between the application and the user make that challenge so much more fun!) This is yet another reason why consistent latency matters so much more than throughput for user experience.

    Leave a comment:


  • Pajn
    replied
    Originally posted by ickle View Post
    Based on the architecture it is not.
    In X, we render directly to the screen.

    In X+Unity, we render to a backbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers (i.e. replace the scanout with Unity's backbuffer), which X does with a pageflip.

    in X+Unity+XMir, we render to a backbbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers, X then copies that to its own frontbuffer, and when Mir requests a new frame, copies that to the buffer provided by Mir. (Now with composite bypass enabled, the buffer provided by Mir is its back buffer, eliminating one of the many copies.) Mir than pageflips between its backbuffer and the scanout.

    What you are seeing here is that most of these benchmarks are not stressing the graphics driver at all [QGears, gtkperf], or do not render to the screen [cairo-trace], and so they show very little difference for that extra two copies every 60Hz. The one that shows some difference, x11perf -comppixwin500, is really just a driver artifact - the error bar indicates that for one run, the driver got stuck using the BCS for the repeated copies rather than RCS. That happens irrespective of the compositing system - it just requires something else to render at the wrong time to trick the driver into believing that we are going to be using the BCS for the near future and so it then continues to use BCS to avoid the overhead of switching rings.

    Throughput testing in applications seems to be around the 10% mark below X+Unity, which itself is about 30% slower than raw X, and we haven't even started to talk about the increased power consumption yet...
    Thank you for a informative and interesting post!

    If I get you correct, what this basically means is that this kind of benchmarks
    doesn't rely mean anything. The differences are too small and the "background
    noise" are to high. Is that correct?

    If so, I guess that would mean that this 10% extra overhead aren?t noticeable in
    real usage as the "background noise" can be much higher than the slowdown itself.

    If so that's pretty great, sure it's still a slowdown however that's what expected.

    What would be more interesting than performance benchmarks would be power
    consumption. Where a small performance degradation isn't noticeable even the
    smallest extra power consumption is when running on battery.

    Michael (I hope you read this forum):
    Could you run some battery benchmarks on X, XWayland and XMir? I think that
    would be very interesting. Especially considering that XWayland is rootless, as
    that is what will mainly be used in the future.
    It would also be nice if XMir were run with both Unity and something slimmer like
    XFCE to see how much of the consumption is in the DE itself.

    Leave a comment:


  • ickle
    replied
    Originally posted by Pajn View Post
    Some test where actually (a tiny bit) better than pure Xorg.
    This surprise me a bit. Is there anyone that can explain how
    that is possible?
    Based on the architecture it is not.
    In X, we render directly to the screen.

    In X+Unity, we render to a backbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers (i.e. replace the scanout with Unity's backbuffer), which X does with a pageflip.

    in X+Unity+XMir, we render to a backbbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers, X then copies that to its own frontbuffer, and when Mir requests a new frame, copies that to the buffer provided by Mir. (Now with composite bypass enabled, the buffer provided by Mir is its back buffer, eliminating one of the many copies.) Mir than pageflips between its backbuffer and the scanout.

    What you are seeing here is that most of these benchmarks are not stressing the graphics driver at all [QGears, gtkperf], or do not render to the screen [cairo-trace], and so they show very little difference for that extra two copies every 60Hz. The one that shows some difference, x11perf -comppixwin500, is really just a driver artifact - the error bar indicates that for one run, the driver got stuck using the BCS for the repeated copies rather than RCS. That happens irrespective of the compositing system - it just requires something else to render at the wrong time to trick the driver into believing that we are going to be using the BCS for the near future and so it then continues to use BCS to avoid the overhead of switching rings.

    Throughput testing in applications seems to be around the 10% mark below X+Unity, which itself is about 30% slower than raw X, and we haven't even started to talk about the increased power consumption yet...

    Leave a comment:


  • Pajn
    replied
    Originally posted by TheBlackCat View Post
    How is it "superior" to be running a rooted X inside Mir/Wayland? It is not that this sort of thing would be fundamentally impossible in XWayland, it is just that nobody implemented it because they didn't see any reason to. So what is the advantage of running rooted X inside XMir/XWayland?
    Wayland and Mir hopes to finally give us a flicker-free boot experience.
    Some DEs wont get ported to Wayland or Mir (XFCE for example have said they will stick to X).
    So if you want to use XFCE with a flicker-free boot experience you will
    have to use Mir as a system compositor, compositing the boot and the
    login manager and then run XFCE in XMir.

    Also I like the idea of full compatibility. Either it's a game, a program or
    a DE it's nice to be able to run in in the compatibility layer. I think the
    golden goal is that anything that runs in X shall be able to run in XMir
    or XWayland without any changes.

    And to everyone in this thread:
    Thanks for finally having a thread were discussions works! I'm so sick
    of the other threads that is so full of shitstorming. Thanks!

    Leave a comment:

Working...
X