X.Org Server Gains Support For Auto-Binding Secondary GPUs To The Screen

[Haxk20]

Now, if only Gnome didn't completely fail to display anything on any GPU, if you start it in Wayland mode when you have an AMD GPU as primary and a BMC (such as ASPEED or Matrox) as secondary...

As far as i know this should be fixed in latest GNOME 3.32. If not then just file a bug report.
When you have an issue dont just wait around for the magical fix to come from nowwhere.
Devs need to know about the issue for it to be fixed.

[beniwtv]

The most sever issue IMHO is that Wayland tried to oversimplify the problem: a separate display server is a *good* thing. We'd have had a whole lot less issues if the Wayland architecture included a display server, running as a separate process, just like X.

No, that leads to this: https://blog.martin-graesslin.com/bl...not-be-secure/

[schmidtbag]

As usual, the people complaining about Wayland don't know what they're talking about. It's the same usual arguments of "hurr durr it doesn't do ____" when decentralizing such features was one of the main reasons for developing it in the first place.

Wayland today on a compositor that actually supports it works just fine.


Anyway, I didn't realize this was an issue. I never really had problems getting secondary GPUs to work.

[Zan Lynx]

Actually this isnt a wayland issue at all. The issue is how is wayland implemented in mutter and i can tell you that it sucks ! If you use Sway or weston for a day you will see that its much better then most users give it credit for. Most users judge Wayland based on Mutter implementation and TBH thats very bad example of good wayland implementation.
Few issues with mutter wayland:
Xwayland apps render at 58 fps and not 60. (Known bug for ages and well OK its xorg bug and not mutter but still a huge bug)
Mouse feels like its slow and jumps and doesnt move smoothly.
Firefox Wayland has graphical artifacts when resizing Window or even making video fullscreen.
And thats just few issues of it.
And Sway doesnt have most of them.
So its just bad wayland implementation.

This seems like its just you.

Wayland gnome-shell on Fedora 30 laptop with 4K display with Intel iGPU: works great.
Wayland gnome-shell on Fedora 30 ppc64-le with Radeon WX 7100: works great.
Wayland gnome-shell on Ubuntu 18.04 Ryzen 3900 with Vega 56: works great. Steam is installed and Pillars of Eternity and Doom 2016 both run a solid 60 FPS.
Wayland gnome-shell on Fedora 30 Ryzen 1700 with Vega 64: also works great.

This 58 fps and mouse lagging just doesn't happen. Really, how can I have used all of these machines and never seen it if it is so common?

[brent]

This seems like its just you.

Wayland gnome-shell on Fedora 30 laptop with 4K display with Intel iGPU: works great.
Wayland gnome-shell on Fedora 30 ppc64-le with Radeon WX 7100: works great.
Wayland gnome-shell on Ubuntu 18.04 Ryzen 3900 with Vega 56: works great. Steam is installed and Pillars of Eternity and Doom 2016 both run a solid 60 FPS.
Wayland gnome-shell on Fedora 30 Ryzen 1700 with Vega 64: also works great.

This 58 fps and mouse lagging just doesn't happen. Really, how can I have used all of these machines and never seen it if it is so common?

People have different expectations and different sensitivity to these performance issues. Some people to this day claim that gnome-shell never really had any performance issues. Even though it provably was a stuttery mess a few releases ago, even on high-end systems with fast GPUs. If you don't care that the compositor sometimes drops to sub-10-fps update rates or even freezes completely or that there are various graphical glitches, you are probably mostly okay.

Especially after you've used macOS for a while, the problems on GNOME become extremely obvious.

Here's a few things that reliably trigger notable issues with GNOME on Wayland for me.

- Try to search for something in the overview. Results in freezes, sometimes hundreds of milliseconds long. On a fast octo-core desktop CPU! Searching for an app or file and then directly opening it by pressing enter typically results in stuttering animations.
- Open the overview, click the app drawer icon and move the mouse. Same thing.
- Moving the mouse over the calendar/notification popup or the top right menu sometimes drops below 60 fps.

This is reproducible on all systems that I have, with and without performance patchsets on top of GNOME.

[Zan Lynx]

Here's a few things that reliably trigger notable issues with GNOME on Wayland for me.

- Try to search for something in the overview. Results in freezes, sometimes hundreds of milliseconds long. On a fast octo-core desktop CPU! Searching for an app or file and then directly opening it by pressing enter typically results in stuttering animations.
- Open the overview, click the app drawer icon and move the mouse. Same thing.
- Moving the mouse over the calendar/notification popup or the top right menu sometimes drops below 60 fps.

This is reproducible on all systems that I have, with and without performance patchsets on top of GNOME.

I believe that's caused by file IO. Which really is something that should not be in a compositor. But, all of my systems are built around flash or Optane NVMe. So I guess file IO is not something I notice much anymore.

[Haxk20]

This seems like its just you.

Wayland gnome-shell on Fedora 30 laptop with 4K display with Intel iGPU: works great.
Wayland gnome-shell on Fedora 30 ppc64-le with Radeon WX 7100: works great.
Wayland gnome-shell on Ubuntu 18.04 Ryzen 3900 with Vega 56: works great. Steam is installed and Pillars of Eternity and Doom 2016 both run a solid 60 FPS.
Wayland gnome-shell on Fedora 30 Ryzen 1700 with Vega 64: also works great.

This 58 fps and mouse lagging just doesn't happen. Really, how can I have used all of these machines and never seen it if it is so common?

Sadly its not just me. This is a known bug. Try to run glxgears and you will see 58fps instead of 60. Games work OK kind of. At least they run at 60fps.

[Haxk20]

People have different expectations and different sensitivity to these performance issues. Some people to this day claim that gnome-shell never really had any performance issues. Even though it provably was a stuttery mess a few releases ago, even on high-end systems with fast GPUs. If you don't care that the compositor sometimes drops to sub-10-fps update rates or even freezes completely or that there are various graphical glitches, you are probably mostly okay.

Especially after you've used macOS for a while, the problems on GNOME become extremely obvious.

Here's a few things that reliably trigger notable issues with GNOME on Wayland for me.

- Try to search for something in the overview. Results in freezes, sometimes hundreds of milliseconds long. On a fast octo-core desktop CPU! Searching for an app or file and then directly opening it by pressing enter typically results in stuttering animations.
- Open the overview, click the app drawer icon and move the mouse. Same thing.
- Moving the mouse over the calendar/notification popup or the top right menu sometimes drops below 60 fps.

This is reproducible on all systems that I have, with and without performance patchsets on top of GNOME.

I have tried MacOS and i hate it but the issues with GNOME are just performance. Because how can DE stutter on modern machine with CPU that has no issue compiling Linux kernel under 10 minutes and iGPU that can run modern games on 60fps at 720p.
This is out right crazy.
Tried different DEs and they dont even stutter. They are smooth as butter but the visuals are not my taste.
Luckily GNOME is getting better each day we go with the perf patches.

[brent]

I believe that's caused by file IO. Which really is something that should not be in a compositor. But, all of my systems are built around flash or Optane NVMe. So I guess file IO is not something I notice much anymore.

No, it doesn't look like it is file I/O. You are right that it is not acceptable that file I/O causes freezes. However, my examples are mostly due to high CPU load (and the single-threaded nature of gnome-shell).

By the way, looks like I'm also suffering from the 58 Hz bug. I noticed at some point that smooth scrolling is broken in all X applications, e.g. Firefox. I guess that is why.

[beniwtv]

No, it doesn't look like it is file I/O. You are right that it is not acceptable that file I/O causes freezes. However, my examples are mostly due to high CPU load (and the single-threaded nature of gnome-shell)

CPU load is getting massively reduced with patches lately. Also, the fact that it's single threaded doesn't mean it can't be concurrent Threading is not easy, it increases bugs and complexity and just isn't always the solution either. Remember how many games were single threaded, a compositor should have no issues in a single thread.

3.34 is a MASSIVE improvement again, and there are more things queued for 3.36 - personally, can't wait.