Fedora 26 vs. 27 Beta Benchmarks, Wayland vs. X.Org Gaming Tests

[Azrael5]

Wayland is better than xorg however the X ahead it means that xorg operates by a translator: obviously this makes Xwayland (Xorg) worst than Xorg. because the comparison is between xorg and xwayland (wayland is transformed into xorg). The right comparison would be between the same xorg applications and wayland applications. Many users are confused by Xwayland thinking that it is wayland but no, it is not wayland.

Real question is how many native wayland programs actually exist, so to take benefit from wayland. The change of paradigm implies a change on program development. My opinion is that a lot of programmation is standardized on xorg as wll as development mind which refuses the new paradigm because of the routine makes the job much more simple than the innovation.

[Brisse]

Azrael5
Most of the issues are present in native Wayland applications as well. As an example, it's very obvious that the mouse is not as responsive under Wayland as it is under Xorg, even during desktop work, especially on a high refresh rate monitor. Not quite as obvious on a typical 60hz monitor though.

They are working on that though, so it's a known issue.

[suspicious_milk]

I'm on Ubuntu 17.10 and running Wayland most of the time these days. Benchmarks show xwayland as fine for gaming but the subjective experience still tells me something is wrong on xwayland because I get obvious stuttering which doesn't show up in benchmarks. It's not game breaking, but it's noticible. Also, the increased input lag of xwayland is very annoying in first person shooters. I often switch back to Xorg when I play those kind of games.

THIS.

Running Fedora 27. Wayland input lag, stuttering, and low FPS is absolutely a deal breaker. Forget all the heavy games, just try Critical Mass and compare X with Wayland. Under Wayland the mouse input is atrocious. I haven't found a game yet that isn't worse under Wayland.

AMD FX-8310 Eight-Core @ 8x 3.4GHz

AMD OLAND (DRM 2.50.0 / 4.13.6-300.fc27.x86_64, LLVM 4.0.1) Radeon HD 8570 / R7 240/340

"
Azrael5
Most of the issues are present in native Wayland applications as well. As an example, it's very obvious that the mouse is not as responsive under Wayland as it is under Xorg, even during desktop work, especially on a high refresh rate monitor. Not quite as obvious on a typical 60hz monitor though.

They are working on that though, so it's a known issue."

I've a 60hz display, and if that's not "quite as obvious", I don't wanna see obvious. If they want adoption, this is a pretty serious issue to fix. Can't wait for all the promises Wayland brings; haven't seen any glimmer of hope yet.

[s_j_newbury]

If there is an input lag, the question would be if the game can't run natively on Wayland, at least with SDL it should be possible by adding the start parameter SDL_VIDEODRIVER=wayland. With this an input lag would be reduced on Wayland.
But I wonder if on XWayland the input has to go through the compositor to XWayland to the game. If yes, it would be interesting if the Kwin approach of a real time process will make a difference.

Indeed, as I try to point out every time Michael publishes such benchmarks. Virtually all SDL2 games work natively under Wayland with SDL_VIDEODRIVER=wayland or by patching SDL2 to try Wayland first as I do locally. I can understand benchmarking XWayland where native Wayland is unavailable but how does it make sense to pipe everything through Xorg unnecessarily?

[Azrael5]

Azrael5
Most of the issues are present in native Wayland applications as well. As an example, it's very obvious that the mouse is not as responsive under Wayland as it is under Xorg, even during desktop work, especially on a high refresh rate monitor. Not quite as obvious on a typical 60hz monitor though.

They are working on that though, so it's a known issue.

in fact, it is question of development. Wayland works and can be improved and upgraded but if the applications are not programmed to take benefit from it or have problems the developers have to improve the compatibility with wayland. In my opinion Xwayland should not been ever used in any case: what is not wayland should be considered deprecated by 1 or 2 years.

[Masush5]

Indeed, as I try to point out every time Michael publishes such benchmarks. Virtually all SDL2 games work natively under Wayland with SDL_VIDEODRIVER=wayland or by patching SDL2 to try Wayland first as I do locally. I can understand benchmarking XWayland where native Wayland is unavailable but how does it make sense to pipe everything through Xorg unnecessarily?

Not really. In my experience, most games using SDL2 (with SDL_VIDEODRIVER=wayland) still make some x11 calls and thus just segfault without Xwayland. For example, many games use GLEW to fetch OpenGL funtion pointers and GLEW uses glx_* funtions which makes it dependend on X.

[Brisse]

Excuse my newbishness, but is there an easy way to figure out which games use SDL2? I just tried SDL_VIDEODRIVER=wayland on Dirt Rally after reading your comments, but it seems to still have been using xwayland. I don't even know which games use SDL2 though, so Dirt Rally may not be one of them I guess.

[totex71]

There is currently a bug with gnome 3.26 that mutter does not redirect fullscreen windows https://bugzilla.gnome.org/show_bug.cgi?id=788493 . It causes input lag, no g-sync, bad performance for games

This has been an issue since at least gnome 3.16. I really hope this will get fixed soon...

[Masush5]

Excuse my newbishness, but is there an easy way to figure out which games use SDL2? I just tried SDL_VIDEODRIVER=wayland on Dirt Rally after reading your comments, but it seems to still have been using xwayland. I don't even know which games use SDL2 though, so Dirt Rally may not be one of them I guess.

You can check if a game uses sdl2 by running

lsof -p "$PID_OF_RUNNING_GAME" | grep -i sdl

As for how to check if it is actually running natively on wayland...
If the game does not depend on steam running, you could try to launch it in weston without Xwayland running and see if it doesn't segfault immediately.
I heard you can also run "xeyes" and if the eyes are not able to follow the mouse curser over a window, it means this window does not use Xwayland.

[Brisse]

I heard you can also run "xeyes" and if the eyes are not able to follow the mouse curser over a window, it means this window does not use Xwayland.

Yes, I used this method when testing Dirt Rally earlier and I've used it before. Seems to be an easy and reliable way to tell if an app is running xwayland or native wayland.