The Current State of Gaming on Wayland

With new emerging technologies and advancements in Linux, one that has been in news often over the past few years is of Wayland: the successor to the X11 display server standard. Although it is now available publicly, most notably for Fedora users (Fedora 25 enables it by default), it is not yet accessible to everyone, and is likely to take several more years before adoption becomes widespread. My interest in Wayland stems from my previous difficulties with hybrid graphics support with X11 (i.e. Nvidia Optimus). With new standards, I expect to see improvements, which is why I’ve done some of my own investigating in how well one can play games under Wayland.

TLDR Version: yes, gaming works on Wayland, provided client and drivers support it.

In order to best explain my experience, and the results one should expect, I am including an explanation of the existing standards and the work that remains to be done, from what I’ve gathered.

What is Wayland?

An emerging paradigm with Linux is the replacement of old technologies and standards with newer and more robust ones. One such software is the X11 display server. This protocol became a standard in 1987, and despite its age is still used today, most popularly implemented through the X.org display server. This protocol is what handles input and output devices (e.g. keyboard, mouse, screen), and allows clients to interact with these cohesively. In short, the X server takes input from your devices, and tells client software like a window manager what to display and where. As decades passed, many the features of this standard became obsolete, or at the very least, less utilized. An X server may tell the client some of the shapes or things to draw to a display, and while this is processed, the client may then draw something different in its place. X11 even has its own font system, which isn’t used either. Despite things like this, server implementations like X.org circumvent undesired behaviour of the standard, and the majority of window managers and desktop environments for Linux use this.

This is where Wayland comes into the equation. Unlike its predecessor, it assumes the client handles all of the rendering. It has been designed to be more low-level, meaning there is less overhead when possible. It also avoids one of the larger problems X11 servers have had mixed results working around: screen tearing. Wayland requires that a frame be fully rendered before it is displayed to a screen. Overall it is intended to be more clean and efficient, and theoretically easier for client implementations to be built.

How Wayland affects gaming

As of writing this, there are two large factors that prevent users from adopting Wayland: public stable implementations, and graphics drivers. Currently, there are not very many window managers (or desktop environments) that have fully functional Wayland sessions available. Gnome shell (as of version 3.22 at least) is considered to be one of the existing stable environments, with many more on the way. With these it’s more a matter of user testing to discover and correct issues, which will lead to more options. The main hindrance for adoption lies with graphics driver support and compatibility. As things stand, nearly any system can support Wayland with the right configuration, but there are several edge cases and exceptions, which should be taken into consideration. After all, without proper drivers, running games becomes difficult or even impossible.

Supported graphics drivers

Intel

Presently, it is most popular to utilize drivers included with Mesa to handle Intel drivers. As Mesa fully supports Wayland, having a system with a relatively recent Mesa version is sufficient.

AMD/ATI

Due to mixed legacy support and compatibility issues, any AMD/ATI video card older than their 3rd generation graphics core, which require Catalyst drivers on the proprietary side, are not supported. These require the usage of open source ATI drivers with Mesa. Presently, many distributions have already ditched legacy Catalyst drivers, due to lack of support and poor stability.

Newer AMD video cards may utilize either open source amdgpu drivers, or the proprietary amdgpu-pro drivers to run a Wayland client. It is generally recommended in this case to also use open source drivers, as they have been known to be stable and provide sufficient performance.

Nvidia

This is where things become complicated. Currently, there are no Wayland clients supported with proprietary Nvidia drivers (at least none of which I’m aware). The reason for this is that presently, Nvidia developers dislike the current preferred technique (GBM) and opt for a different one (with EGLStreams) to run Wayland on their drivers. Although they have added support for this, they desire a new alternative API to handle the implementation. For this reason, many window managers will not be implementing support until this API is finalized, and few will develop support for the existing method in the mean time. Gnome shell 3.24 is expected to be one of these few, but this release has not yet arrived. Even then, developers state that while native Wayland applications will run, using XWayland (most applications currently) with these drivers will be a whole other problem to tackle.

Update: With Gnome Shell 3.24 being released, it seems that yes, it is able to run under Wayland with proprietary drivers. The only problem that is still present is that running applications under XWayland is troublesome, and will generally not work correctly since this is not yet capable of sharing the same binary driver. This means that, unless a game is running natively on Wayland, it will likely not be functional.

In terms of the open source nouveau drivers, these fully support Wayland, and unlike AMD/ATI cards, the same drivers are used here regardless of which generation of GPU is utilized.

Hybrid graphics

These setups include systems where both integrated graphics from the CPU (typically from Intel) can be utilized alongside a discrete GPU, such as with Nvidia Optimus technology, or AMD switchable graphics. As things stand, Wayland clients require open source drivers to be installed for both GPU types. This allows DRI Prime offloading to work, so the client may send rendering requests to a separate device.

Technically speaking, proprietary drivers are also not supported here, most notably through Nvidia. This may be frustrating to many users, as the open source nouveau drivers are known not to perform as well as those provided by Nvidia. I have discovered though that a workaround works quite well. The Bumblebee project, while fairly old at this point, uses certain hacks to allow X.org clients to perform rendering of applications on a separate device. I have utilized this for several years to run 3D applications such as games using my Nvidia GPU with proprietary drivers. Since Wayland has a compatibility layer with X11 through XWayland, I’ve found that running applications with Bumblebee in Wayland also works.

How does gaming hold up?

Put simply, games run great. Presently my setup uses Gnome Shell 3.22 and Bumblebee for hybrid graphics. What allows this all to work now is the last major update from X.org: xserver 1.19. This corrects a few bugs around relative mouse movement, allowing first person games to correctly handle the mouse without spinning the screen randomly. This improves not only the results with Bumblebee, but with most applications without it, since many will be running through XWayland compatibility layer in any case. By playing through Wayland, I’ve also managed to circumvent an issue that arose for me with the last gnome shell update, which hindered performance of certain games. What also really impressed me is the way full screen applications are handled. I’ve had issues in the past, with X.org server, where a full screen game seems to grab all the input, and I have trouble switching out of it without the screen acting strange, or finding myself unable to click on other windows. In Wayland, this all felt smooth and seamless. Even running games through Wine felt improved with this. The only downsides to my setup are that, because I’m using Bumblebee, Vulkan support is lacking. It may be added eventually, however it is not currently available. Also, since I’m using proprietary drivers, I still cannot use an external display through HDMI, since this is passed through the GPU. I believe this is meant to work with open source drivers, however I have not tested this to confirm it. My screen does flicker when inserting an HDMI cable (more than what would happen in X.org), however that is the extent of it.

Conclusion

Bottom line, Wayland is here, and it’s ready (at least with Gnome Shell). For users with open source drivers, I highly recommend giving it a shot, provided it’s available on their distribution. It does require some of the more recent software updates (notably xorg-server 1.19) for the best possible experience. Sadly Nvidia users will still be kept waiting, since the best performance typically comes from the proprietary driver. Personally, I will probably bounce between the two (as simple as logging out and back in), until I can get Redshift working on Wayland. At that point, I expect I’ll be sticking with it, and not looking back.