AMD Radeon Linux Gaming Performance At Parity Between KDE Plasma 6.0 X11 vs. Wayland

[mrg666]

From the article:


You're comparing an X11 session to a game running under XWayland which is an Xorg server running as a Wayland client - why would you expect to see a benchmarking difference? All you are showing is that Wayland is just as efficient at invoking an Xorg server as running an Xorg server natively. But isn't that to be expected after all these years of development and refinement?

Nope, read the following

https://wayland.freedesktop.org/xserver.html

Both graphics from wayland and x clients are drawn by the same wayland compositor. Xwayland is just shim layer not a real xorg server. It does all drawing via wayland compositor

Edit: and it can only be faster when client directly talks to wayland compositor.

[Brittle2]

Not sure if you meant this to be dripping with irony or you're just too much of a x11 crusader to notice. But you are complaining about a perceived shortcoming in the performance of a protocol on a post about how the performance is nearly identical between the 2. Not sure if calling people "blissfully ignorant who keep parroting bullshit" applies here.

also wine still uses xwayland so the performance is going to improve onse removed that

[SSJBurger]

bspwm outperforms KDE Wayland, river wm and sway wm on Alpine Linux in Xonotic and 5 Steam games. I think Wayland is still slower and less reliable.

Impressive mind sharing the benchmark you are talking about?

[qarium]

Thanks for the benchmarks, but I doubt this can shut the blissful ignorants who keep parroting bullshit, since they never look at facts to begin with.
Wayland's issue isn't performance directly, it's lack of features (by design). I say directly, because some things like childing yourself to another window (for Wine's virtual desktops for instance) require more overhead due to lacking features that X11 has natively, so the performance will be lower (although it's not perf directly but input lag and latency). This is due to its stupid design and stubborn devs, and yes, it's the protocol's fault.
Anyway they should stop using the Linux kernel since that's also tech from the 90s. Who cares it got a lot of updates since then, right?

you really have a deep misunderstanding of course x11 has many features but all these features do not come free of cpu cycled used for this feature.
also keep in mind most benchmarks are not wayland vs x11... instead it is Xwayland vs x11...

its already known that if you skip xwayland and go with native wayland you have higher performance.

[Weasel]

you really have a deep misunderstanding of course x11 has many features but all these features do not come free of cpu cycled used for this feature.
also keep in mind most benchmarks are not wayland vs x11... instead it is Xwayland vs x11...

its already known that if you skip xwayland and go with native wayland you have higher performance.

I said feature, but it's not exactly a "feature" that requires coding, just allowing it. It's not really a lot of code to execute, on the contrary, I think Wayland has more code to block this shit LOL.

[Weasel]

You're quite harsh to yourself there.

Yet I'm always the one providing facts, links, while you guys literally just post "never had issues with Wayland." Nobody gives a flying fuck of your anecdotal experience OR what you use the PC for.

Let's not forget shills like you who said "Wayland is faster than X11" 10 years ago LMFAO, even though it's still slower due to bugs.

Get fucked by facts as always. Cope harder.

[Weasel]

How did it receive updates? Has the Linux kernel been declared abandonware, as other things being discussed right here have been declared?

Show me where it was declared officially, not by a Wayland clown.

[Weasel]

What overhead do you expect, assuming a architecture around dmabufs sharing? I don't see why e.g. additional IPC would result in input lag in any human-conceivable form (if we define that at say 0.5 ms).

X11 has IPC too, but Wayland would have more IPC, because now the process that nests child windows of other processes has to do composition itself, and then IPC back to Wayland.

In X11 there's only one IPC, from all processes to the X server/compositor.

In Wayland processes first have to IPC to the process embedding them, then that process IPCs to Wayland compositor. Because it does not allow child windows to be from another process. Artificial limitation btw, probably has even more code to block it!!

Yes, in the fucking protocol. Also, see, apps (and malware) can workaround it, so what the fuck is the point of it?

[andyprough]

Xwayland is ... not a real xorg server.

Wrong. From the page you are citing: "The server still runs the same 2D driver with the same acceleration code as it does when it runs natively."

That's the point. Of course there's no real benchmark difference - it's the same thing. Lots of compositors and window managers will give similar results when the same Xorg server is doing the same work in the background.

[mSparks]

Ive had a few projects that Ive piled more effort than I would have liked into refactoring stuff on the promise of better performance, only to be left gutted when that better performance didn't materialise.

But the scale of this wayland flop must be unprecedented in software engineering.

All that effort to at best par what has existed for years/decades before, damn thats gotta sting.