XWayland 22.1.1 Released - Fixes Some Windowed Apps Stuck To 58 FPS

[mdedetrich]

Yes, the issue which started this sub-thread only happens with the nvidia driver (and maybe some proprietary drivers for embedded GPUs). Upstream drivers have to support implicit synchronization (and can optionally support explicit synchronization as well).

Right and the point is that the default should be explicit synchronization, not implicit. If Linux is enforcing implicit synchronization, its enforcing a technically inferior solution.

If that's the case, I'd have expected someone to have made an explicit synchronization prototype which demonstrates it by now.

Colour me skeptical, though. radeonsi/RADV using implicit synchronization are competitive with nvidia's drivers using explicit synchronization. I don't think James means to suggest that with explicit synchronization, the former would wipe the floor with the latter.

BTW, as hinted above, implicit vs explicit synchronization isn't a binary choice. Jason Ekstrand posted a patch series which showed converting between the two as needed is possible.

It isn't as simple as you put it, implicit synchronization works okay if you have a reduced problem space/and or higher level API's. For example since most games still run in DirectX <= 11/OpenGL you won't find too much of a difference between between implicit and explicit synchronization because since the API's are so high level and a lot of state is deliberately (by design) hidden this synchronization is handled by the driver.

The problem occurs with newer API's (i.e., like Vulkan) and with newer protocol's like Wayland (Wayland is still technically implicit synchronization in design but after realizing how stupid this decision is there is some movement to change it). In these cases explicit is strictly better if you want better performance. https://lwn.net/Articles/814587/ is an extremely good article on the matter. In fact technically speaking in general explicit is far superior to implicit, its just that the performance difference is larger with the mentioned use cases, especially when you get to massively concurrent/multithreaded problems explicit synchronization along with explicit state is the only way to have sane performance (and I actually deal with this all the time in a different context, i.e. parallel backend services).

The point here is that NVidia's driver is actually too correct, in the sense that because they care about performance so much that they don't even bother with implementing implicit synchronization when its not needed and they don't want to because its in reality the worst option.

I am sorry to burst your bubble here, but the issue here specifically is that Linux is relying on technical inferior/outdated designs. As noted in the previous article, the Linux ecosystem is well aware of this and this is exactly what James point is, there is no reason for Nvidia to spend time and effort implementing an inferior design (implicit synchronization) for the XWayland compositor. The best solution is for X to support explicit synchronization (which they should have at some point but for reason's he stated they kind of did not). Wayland being designed with implicit synchronization was also stupid but thats a discussion for another day.

As a last point, NVidia has been complaining about this exact same problem for almost a decade now, in fact their main reason for not even taking Wayland seriously is because Wayland didn't solve what NVidia sees as a one of the biggest problems with Linux and its graphics stack, i.e. implicit synchronization. This is the main reason why NVidia went to all of the trouble to create EGLStreams. Unfortunately a lot of cases of "shoot the messenger" because "NVidia is evil" meant that their complaints were largely completely ignored. The larger problem is that because Linux's desktop market share is so miniscule, no one even really cares about performance there which along withe unnecessary "everything must be a simple read/write buffer as a file" mantra (which works until it doesn't, and in this case it doesn't) didn't help.

[MrCooper]

Yes and thats why its outdated and incompatble with how modern GPU's work. This isn't an issue with NVidia,

Yes, the issue which started this sub-thread only happens with the nvidia driver (and maybe some proprietary drivers for embedded GPUs). Upstream drivers have to support implicit synchronization (and can optionally support explicit synchronization as well).

open source drivers have similar problems with API's like Vulkan which are deliberately designed to give lower level access to the GPU. You can get away with implicit synchronization for high level API's like OpenGL but then you quickly start having issues when you go lower level.

The matter of fact is that just as stated in that thread, implicit synchronization is no longer the correct model for modern GPU's. If you want really good performance then representing everything as simplistic read/write buffers that don't have real explicit synchronization is just going to cause problems.

If that's the case, I'd have expected someone to have made an explicit synchronization prototype which demonstrates it by now.

Colour me skeptical, though. radeonsi/RADV using implicit synchronization are competitive with nvidia's drivers using explicit synchronization. I don't think James means to suggest that with explicit synchronization, the former would wipe the floor with the latter.

BTW, as hinted above, implicit vs explicit synchronization isn't a binary choice. Jason Ekstrand posted a patch series which showed converting between the two as needed is possible.

[mdedetrich]

Implicit synchronization is how the Linux graphics stack has been working for two decades. In all that time, none of the proponents of explicit sync have stepped up to make at least a working prototype to demonstrate the claimed benefits. I for one am not holding my breath.

Yes and thats why its outdated and incompatble with how modern GPU's work. This isn't an issue with NVidia, open source drivers have similar problems with API's like Vulkan which are deliberately designed to give lower level access to the GPU. You can get away with implicit synchronization for high level API's like OpenGL but then you quickly start having issues when you go lower level.

The matter of fact is that just as stated in that thread, implicit synchronization is no longer the correct model for modern GPU's. If you want really good performance then representing everything as simplistic read/write buffers that don't have real explicit synchronization is just going to cause problems.

This btw was one major reason why, even with all of its faults, NVidia tried to push EGLStreams, its because the EGLStreams has an expicit asynchronous API which didn't have any performance penalty.

So yeah you can have the conclusion that "implicit synchronization" is the way that Linux works, in which case Linux is outdated by 2 decades because the other main OS that treats their graphics stack seriously (Windows) doesn't have this model either, and for good reason.

[MrCooper]

Yes I've seen that mentioned by James Jones from NVidia, but why isn't Xorg affected by this lack of implicit synchronization?

Presumably their Xorg driver handles implicit synchronization. With Wayland, the kernel driver would need to handle it instead.

This is why milliseconds should not be used anymore (not for video rates and not for audio buffer sizes as well). It's too imprecise for the exact value of 16 2/3ms.

The article was slightly misleading there. The issue wasn't an incorrect calculation, it was the fallback timer getting hit at all. The fix makes the MSC tick in sync with the Wayland compositor's redraw cycle, as intended.

I just read this issue and the last comment by James Jones at https://gitlab.freedesktop.org/xorg/...7#note_1275874 indicates in some ways how backwards the Linux GPU stack is. It appears that a lot of Linux GPU developers still have their heads (and in effect implementations of software) stuck in an outdated 90's views of how graphics cards/drivers work.

Implicit synchronization is how the Linux graphics stack has been working for two decades. In all that time, none of the proponents of explicit sync have stepped up to make at least a working prototype to demonstrate the claimed benefits. I for one am not holding my breath.

[Hibbelharry]

I just read this issue and the last comment by James Jones at https://gitlab.freedesktop.org/xorg/...7#note_1275874 indicates in some ways how backwards the Linux GPU stack is. It appears that a lot of Linux GPU developers still have their heads (and in effect implementations of software) stuck in an outdated 90's views of how graphics cards/drivers work.

You noticed his rant is directed towards Xorg and the old and outdated assumptions being baked into it? And that a proper fix would once again be to change X.org fundamentally? Thats just one more reason why X11 has to go.

[mdedetrich]

At xwayland issue discussion someone mention that back to eglstream can fix it, but my gnome always fallback to X, with note that eglstream not working for dual gpu setup.

I just read this issue and the last comment by James Jones at https://gitlab.freedesktop.org/xorg/...7#note_1275874 indicates in some ways how backwards the Linux GPU stack is. It appears that a lot of Linux GPU developers still have their heads (and in effect implementations of software) stuck in an outdated 90's views of how graphics cards/drivers work.

[frosth]

I'm on 510.54-11 right now. I'll try upgrading once it's available in the extra repo.
....
Yes I've seen that mentioned by James Jones from NVidia, but why isn't Xorg affected by this lack of implicit synchronization?

- 510.60.02 does nothing for that thing.
- it's only wayland/gbm issue.

I found two partial solution
1) lower display refresh rate (if game fps match display refresh rate problem is gone)
2) prevent from load nvidia-drm module or unload it before start DE (break synchro), main problem gone but there is a lot of oridinary vsync stutters
3) back to X and wait for NVIDIA move

At xwayland issue discussion someone mention that back to eglstream can fix it, but my gnome always fallback to X, with note that eglstream not working for dual gpu setup.

[tildearrow]

Incorrect calculation handling led to the MSC ticking at ~58Hz.

This is why milliseconds should not be used anymore (not for video rates and not for audio buffer sizes as well). It's too imprecise for the exact value of 16 2/3ms.

[remenic]

• What NVIDIA driver version do you have? I strongly recommend using latest one (current is 510.60.02).
• You can try disabling framebuffer compression for iGPU. This thing caused massive artifacts for me like 2 years ago and I spent lots of time finding it.

I'm on 510.54-11 right now. I'll try upgrading once it's available in the extra repo.

I got excited for a moment when you suggested that option, but the problem has not disappeared. I checked /sys/module/i915/parameters/enable_fbc to make sure it was disabled and tried it with the option enabled as well, but it didn't make a difference sadly. Thanks for the suggestion anyway!

There's no easy solution unfortunately. It's because the nvidia driver doesn't support implicit synchronization.

Yes I've seen that mentioned by James Jones from NVidia, but why isn't Xorg affected by this lack of implicit synchronization?

[andre30correia]

looks like my problem, cant play using nvidia card in prime systems