Does The Display Server Matter? The Latest Mir vs. Wayland Argument

[toka]

Future

Apple's Quartz, Android's SurfaceFlinger and Cannonical's Mir work kinda similar and each was conceived as the easy cheap way out of X11:

• trimm lots of fat from X
• remove GLX elephant
• switch to a more lean context handler like EGL/AGL
• and then finally add some simple but functional compositor integrated into the server to handle the eye candy, shadows, etc.

The basic concept of Wayland is way more radical, basically behaves like a language like OpenCL or OpenGL or Mantle but to speak GUI (instead of 3D) needs directly into the GPU without middle mans, aka you use wayland language to create your own unique Wayland compositor and or server and/or client that you can transform in any way you feel like it using any supported GPU draw language(like opengl/es or GPU specific ASM or even c/c++ if hardware accel is not available), so the capabilities of wayland are incredibly flexible only limited to hardware limitations and since is basically operates as close to the hardware as is possible without reach ASM, the performance is impressive as long as the render code is efficient but wayland itself is basically hit free to the hardware.(very diluted to make it more easy to digest)

Wayland is way harder and more expensive to develop than the three counterparts desscribed above, but the capabilities it introduces will pay off in the long run (in the short run it won't be as fantastic because first developers need to match what you are used to today)

For example the Wayland protocol makes it possible to smoothly "release" the Wayland compositor (KWin/Mutter/Enlightement) and let a 3D game engine itself composite and parallelize its own render pipe in the GPU's/operations, seriously improving game perfomance. (this is not possible with any other today techs). This is considerd best and swap to screen when its considered right for the game engine, etc.(specialized nested compositing) and then just send control back to desktop optimized compositor(kwin/mutter/etc) when exited or switched back.

There are Benchmarks on Phoronix, that prove, that running a compositing window manager lowers 3D performance in a game.

and well another nasty miriad of possible scenarios/optimizations with wayland that wont have time to explain them all

Uh, that is really a bit hard to digest. The way you're explaining it: you are a programmer and non-native English speaker.
A BIG THANK YOU for your explanation, I am sure, it will help me along the way.

In case the illustration http://en.wikipedia.org/wiki/File:Th...and_glamor.svg is correct, and also, in case AMD is going to switch from their own in-kernel blob to the DRM/TTM combo of the FOSS driver, then, the illustrated stack is the one to put your money on:

• kernel-space:
  • we can expect the DRM/TTM in-kernel solution to support the conversion of CPU/GPU in a performant way, I mean the HSA hardware implementations (e.g. http://en.wikipedia.org/wiki/AMD_Acc...Implementation)
• user-space:
  • the Wayland-based user-land is a "fat"-free start engineered for the future
  • that thanks to XWayland continues to support software that relies on libX/libXCB instead of using libwayland-client
  • thanks to GLAMOR, the fuss with the additional graphics driver for the xserver will go away (finally)

[V10lator]

Proprietary games are going to use whatever SteamOS goes with. Whatever is left if said developers you propose existing actually exist are going to be a small number of very niche applications that aren't really holding back the progress of wayland, because all of the applications that most people actually care about are or have a force backing them that ensures that they will be ported to wayland.

I don't have a link right now and maybe I'm wrong but didn't Valve tell to stay with X.org? That makes your "small number" a bit bigger and I wouldn't call games "niche applications".

[valeriodean]

I don't have a link right now and maybe I'm wrong but didn't Valve tell to stay with X.org? That makes your "small number" a bit bigger and I wouldn't call games "niche applications".

While the nvidia and amd remain in the X world, there is no choice to do at all by Valve.
It isn't realistic sell the Valve's machine powered by Wayland if the user cannot use the proprietary blob. The gamers want the best from their hardware and so far that it's possible only with the binary blog, then X.org.
Other than the driver support, the reasons (either architectural or design) to stay on X don't exist.

[erendorn]

It's not a technical problem, in that one is superior to the other - it's simply that the existence of Mir forces a split between "Canonical" and "everyone but Canonical"... developers don't want to support both, so we end up with this unfortunate battle for supremacy...

Well it's not really a battle for supremacy, in the sense that the "everyone but Canonical" cannot use Mir. So wayland is here to stay, that's quite a given. It's a battle for "will we need to support one or two solutions" (in the usual Linux ecosystem).

[Luke_Wolf]

I don't have a link right now and maybe I'm wrong but didn't Valve tell to stay with X.org? That makes your "small number" a bit bigger and I wouldn't call games "niche applications".

Here's the fundamental point you're missing there. Developers writing said games aren't wanting to support either Wayland or Mir (let alone both), they want to support SteamOS, period. They couldn't quite frankly care less about what display server it's running just so long as it's the one running on SteamOS. But yes you're correct that around the time they launched that they told developers to stick with X.Org, however that was over a year ago and we still do not have the big 2 (GNOME and KDE) using Wayland yet, and won't for months at a minimum, let alone have distros running it by default. Therefore that was a reasonable statement by them, and we'll see what happens in the future. If nothing else they're likely to go wayland just based upon the fact that they're using Gnome Shell as the desktop for SteamOS that they're running Big Picture overtop of.

[giucam]

to complete the idea here, in resume(and in this order) Quartz, Surface Flinger and Mir work kinda similar and were conceived as the easy cheap way out of X11, aka trimm lots of fat from X, remove GLX elephant and switch to a more lean context handler like EGL/AGL and then finally add some simple but functional compositor integrated into the server to handle the eye candy, shadows, etc.

the basic concept of wayland is way more radical, basically behaves like a language like OpenCL or OpenGL or Mantle but to speak GUI(instead of 3D) needs directly into the GPU without middle mans, aka you use wayland language to create your own unique compositor and or server and/or client that you can transform in any way you feel like it using any supported GPU draw language(like opengl/es or GPU specific ASM or even c/c++ if hardware accel is not available), so the capabilities of wayland are incredibly flexible only limited to hardware limitations and since is basically operates as close to the hardware as is possible without reach ASM, the performance is impressive as long as the render code is efficient but wayland itself is basically hit free to the hardware.(very diluted to make it more easy to digest)

wayland in this case is way harder and expensier to develop that other counterparts but the capabilities will pay in the long run(in short term won't be as fantastic because first devs need to match what you are used to today) but for example in wayland(which is not possible with any other today techs) can improve games by releasing the desktop compositor(kwin/mutter/etc) and let the game itself composite and parallelize its own render pipe in the GPU's/operations is consider best and swap to screen when its considered right for the game engine, etc.(specialized nested compositing) and then just send control back to desktop optimized compositor(kwin/mutter/etc) when exited or switched back.

and well another nasty miriad of possible scenarios/optimizations with wayland that wont have time to explain them all

When did you dream this stuff? Wayland does not behave like a language. Did you just make this up or did you read it somewhere? Besides, neither OpenGL/CL nor Mantle are languages (though they contain one).
Wayland compositors are not much different from Mir ones, they are just modern display servers, like SurfaceFlingers. Of course there are differences, but they are rather minor.

[toka]

It isn't realistic sell the Valve's machine powered by Wayland if the user cannot use the proprietary blob. The gamers want the best from their hardware and so far that it's possible only with the binary blog, then X.org.
Other than the driver support, the reasons (either architectural or design) to stay on X don't exist.

Don't the Nvidia propietary drivers support EGL?
Wasn't EGL 1.5 released at the GDC?


I don't see your problem.

Question: there were/are some Wayland-specific stuff added to the EGL in Mesa. Ist this sill required or was it adopted into EGL 1.5?

[GreatEmerald]

Question: there were/are some Wayland-specific stuff added to the EGL in Mesa. Ist this sill required or was it adopted into EGL 1.5?

There's the buffer age extension, but it's optional.

[Pajn]

And that's it: Mir is the only one speaking the Mir "protocol". Even if somebody other would want to speak it it wouldn't work in the long run as the "protocol" isn't stable. In other words: There is no protocol, it's just some APIs the Mir server and the Mir compositor speak to each other. But these APIs will never be stable nor are they meaned to be talked by anything other.

Learn the difference between protocol and API and stop embarrassing yourself.
The Mir protocol isn't stable and isn't suppoes to be used by end users. The libmir API is.

I don't have a link right now and maybe I'm wrong but didn't Valve tell to stay with X.org? That makes your "small number" a bit bigger and I wouldn't call games "niche applications".

Valve recommends using SDL2, wich Valves own games are using.
As SDL2 supports both Wayland and Mir those games can run there without any problem at all.

Question: there were/are some Wayland-specific stuff added to the EGL in Mesa. Ist this sill required or was it adopted into EGL 1.5?

To support XWayland (and XMir) support needs to be added to the X userspace driver.
This however is due to how X is designed, not Wayland nor Mir.

[V10lator]

Learn the difference between protocol and API

Maybe you should tell it? According to Wikipedia there isn't a real difference: http://en.wikipedia.org/wiki/API#API_and_protocols