Fedora 21 Gaming Benchmarks: X.Org vs. XWayland To End 2014

[kalrish]

Why is Wayland slower than X?

All we heard about is that X is legacy, bloated, synchronous and has lots overhead.

XWayland is slower than X, because it is an X server which does all the work a normal X server would do *plus* additional work. It **has** to be slower. However, it is not to be confused with Wayland.

It's why I've never seen the point of running XWayland or XMir or whatever. Just plain X would perform better and it's readily available.

X is indeed better for full-screen applications that are not Wayland-capable, such as many games. An "expert" user would close the Wayland desktop session, switch to a TTY and start an X server to play there with better performance, but that is not very practical, and certainly nothing that can be expected from the "average" user, which would prefer to simply launch the game, even if it runs under XWayland with worse performance. Do you suggest dropping Wayland entirely because of those X-only applications, or starting an X instance on another TTY...? If the later, I guess it would be difficult for the Wayland session manager to determine whether the application needs it.

As has been said before, a fair native Wayland vs. native X benchmark would reveal that Wayland is better, not only for developers (which, after all, are the ones behind it) but also performance-wise.

[johnc]

Wayland cannot "counter" the performance hit due to XWayland. At most, it can be transparent in terms of performance.

Sure it can, if the server <-> hardware performance is markedly better than X, it could make up for the loss due to the X <-> Wayland translation.

But it won't be.

[johnc]

As has been said before, a fair native Wayland vs. native X benchmark would reveal that Wayland is better, not only for developers (which, after all, are the ones behind it) but also performance-wise.

We are still waiting for such a fair benchmark. We have been hearing this for years and your assertion that "Wayland is better" in performance comes across as quite confident despite the dearth of evidence. Which, as far as I know, the extent of what we have is some benchmark from an embedded GPU that has a half-baked X driver.


Myself, I'm going to wait until nvidia releases its wayland driver and we have a valuable benchmark application that can be used to draw an apples-to-apples comparison. If Wayland or Mir or whatever is markedly better and has all the features I need, I'll be one of the first to make the switch. But I'm going to need to see a lot more than hype before making that decision.


People seem to get hung up on this idea that X is this monstrosity from the 80s with a bunch of "legacy, crufty, bloated code" without recognizing that no modern application uses that framework. It's just about all DRI2 / DRI3 now. And while I'm not saying that DRI2 is a perfect mechanism, it's not what people are claiming it is when they deride X with this appeal to the "30-year-old code base".

[Xaero_Vincent]

Shouldn't XWayland performance be able to offset native X11 performance if the native Wayland graphics driver (which would be the only video driver running) offers greater performance than the native X11 driver? Sure this would mean that native Wayland games would offer even higher FPS but at least it would offset a loss of frames per second comparing XWayland versus X.Org Server.

[xeekei]

We are still waiting for such a fair benchmark. We have been hearing this for years and your assertion that "Wayland is better" in performance comes across as quite confident despite the dearth of evidence. Which, as far as I know, the extent of what we have is some benchmark from an embedded GPU that has a half-baked X driver.


Myself, I'm going to wait until nvidia releases its wayland driver and we have a valuable benchmark application that can be used to draw an apples-to-apples comparison. If Wayland or Mir or whatever is markedly better and has all the features I need, I'll be one of the first to make the switch. But I'm going to need to see a lot more than hype before making that decision.


People seem to get hung up on this idea that X is this monstrosity from the 80s with a bunch of "legacy, crufty, bloated code" without recognizing that no modern application uses that framework. It's just about all DRI2 / DRI3 now. And while I'm not saying that DRI2 is a perfect mechanism, it's not what people are claiming it is when they deride X with this appeal to the "30-year-old code base".

Exactly! It's all DRI2/DRI3 and KMS today. So why the hell do I still need to have bloody X installed?! Wayland is more about removing the useless middleman than replacing it.

[johnc]

Exactly! It's all DRI2/DRI3 and KMS today. So why the hell do I still need to have bloody X installed?! Wayland is more about removing the useless middleman than replacing it.

There are a variety of bullet points people use to promote Wayland. I'm just saying that people should temper their expectations regarding the actual end-user experience. If you think it's going to be much better than what we have w/ X right now, I think you're going to be surprised.

That's not to take away from some of the good things about Wayland (easier code to maintain, etc.).

[kalrish]

We are still waiting for such a fair benchmark. We have been hearing this for years and your assertion that "Wayland is better" in performance comes across as quite confident despite the dearth of evidence. Which, as far as I know, the extent of what we have is some benchmark from an embedded GPU that has a half-baked X driver.


Myself, I'm going to wait until nvidia releases its wayland driver and we have a valuable benchmark application that can be used to draw an apples-to-apples comparison. If Wayland or Mir or whatever is markedly better and has all the features I need, I'll be one of the first to make the switch. But I'm going to need to see a lot more than hype before making that decision.


People seem to get hung up on this idea that X is this monstrosity from the 80s with a bunch of "legacy, crufty, bloated code" without recognizing that no modern application uses that framework. It's just about all DRI2 / DRI3 now. And while I'm not saying that DRI2 is a perfect mechanism, it's not what people are claiming it is when they deride X with this appeal to the "30-year-old code base".

You are right with regard to the abscence of proper desktop tests. However, there have been technical (presumably reliable) arguments about how it would be more performant and more energy-efficient. These items have both been proven in the case you mention, by Collabora, if I recall correctly, so at least it seems to win in the embedded space, although I don't know if it was really fair or not. Leaving that aside, and looking to Wayland from a developer/maintainer perspective, it is ostensibly better designed (I won't expand here; the benefits have already been explained). In summary, there may not be many advantages for the user --if at all, in many cases--, but developers and maintainers seem favorable towards it, and they generally go for what is technically better. Then there are, of course, those that are commonly called "fanboys", with one foot on the user camp and the other one on the technical side...

I agree with you about the "popular impression". The social mindset is not funded in facts (whatever they are...), but in assertions, be they more true or more false. However, denying something because it is popular (or unpopular) is as belief-driven as the majority.

As an user, it is perfectly fine for you to care only or mostly about what you see. That's how it should be, the "ideal of the user". Those tech-savvy users are sometimes noisy pests that do not contribute yet speak more than those who do. But, honestly, I look forward to the improvements that (it seems) Wayland will bring, mostly to the indirect ones. It has already brought a handful of them (further separating the graphics implementation from the display server, which is needed for rootless GPU computing, and that stops the kind of duplication that has been taking place between Mesa and X video drivers; general cleaning of many components of the stack; ...).

[dungeon]

So just 5-10% slower, that looks fine

As a numbers of course, numbers looks fine... not that i want to use Wayland, let alone that combination

[Xaero_Vincent]

While X11 code has legacy cruft, that doesn't mean that some of the old junk hasn't been deprecated or removed. For instance, look at the Change log between 7.5 and 7.7 releases.

Old junk and unmaintained drivers removed:

• Xsdl - experimental kdrive server using SDL that was never finished
• Frame buffer support in XF86DGA
• Multibuffer extension in X servers - deprecated since the 90's
• X server libraries: cfb, afb, mfb/xf1bpp
• X server support for obsolete/unused/broken/unmaintained extensions: AppGroup, EVI, MIT-SUNDRY-NONSTANDARD, TOG-CUP, XTrap, XFree86-Misc, XEvIE
• X server command line flags: -co, -bestrefresh, -showunresolved
• X server bundled utilties: xorgconfig, xorgcfg, ioport, kbd_mode
• Unmaintained X server variants: Xgl, Xprt (moved to separate xprint git repo)
• xf86-input-acecad: Acecad Flair
• xf86-input-aiptek: Aiptek USB tablet
• xf86-video-apm: Alliance Pro Motion
• xf86-video-chips: Chips & Technologies
• xf86-video-i740: Intel i740
• xf86-video-rendition: Rendition Verite
• xf86-video-s3: S3 (not ViRGE or Savage)
• xf86-video-s3virge: S3 ViRGE
• xf86-video-sisusb: SiS Net2280-based USB
• xf86-video-suncg14: Sun CG14
• xf86-video-suncg3: Sun CG3
• xf86-video-sunleo: Sun Leo (ZX)
• xf86-video-suntcx: Sun TCX
• xf86-video-tseng: Tseng Labs
• xf86-video-xgi: XGI
• xf86-video-xgixp: XGI Volari 8300

[Adriannho]

So is XWayland finally a finished product?