KDE Enjoys Improvement For Much Better NVIDIA Wayland GBM Experience

[Azrael5]

https://wiki.qt.io/Qt-contributors-s...2014_QtWayland
Horrible reality qtwayland is 2014.

https://lists.x.org/archives/xorg-de...ay/049668.html
X11 is still shoving almost everything though a single thread until 2016.

So yes qtwayland looked at x.org X11 server and copied the mistake. Yes its taken them 6 years to finally start fixing it copied mistake.

You were not thinking this was a copied mistake.

Should this patch fix the known switching problem between the two graphical platform?

[oiaohm]

I'm not sure how a history lesson is relevant here. I'm just curious how this misplaced polling didn't cause performance issues before. The obvious explanation would be polling takes much longer on Nvidia hardware than on AMD or Intel, but that's also strange and I have no data to back that up.

AMD and Intel on Linux are using mesa. Mesa has a lot of polling that bipassing the X11/Wayland protocol by using different features in drm/dri layer in the Linux/freebsd... kernel and also mesa uses a few different parts of the wayland protcol to say compositor notify me of change instead of polling the compositor all the time. Yes the way nvidia has implemented their GBM stuff does a lot more polling over Wayland protocol. So its not that that polling at the hardware is faster or slower its more how much polling you attempt to shove though the Wayland protocol if problem appears or not.

Please note there are different bugs in gstreamer that poll wayland heavily as well and this was also causing issues as well with amd and intel gpus as noted in the kde issue/bug with the QT Wayland being the way it was.

So lack of optimisation on the Nvidia side of their GBM code and goof ups in the gstreamer code that exposed this problem with QtWayland. Of course this does not justify having the single thread for everything. Yes this very much the same as the single threaded input of X11 x.org server of old where it worked until you really pushed it then it does not. Multi threading this removes the problem or at least means you have to push a insane amount harder to cause the problem to appear.

[oiaohm]

Should this patch fix the known switching problem between the two graphical platform?

The issue mentions nothing about that problem. So who knows basically. Might improve it and might not.

[C8292]

For those curious on testing on fedora: https://bodhi.fedoraproject.org/upda...022-09f6750812

[obri]

Very, very nice. But the question remains: why did it take so long to realize you don't poll on a thread that has other stuff to do?

This question is mainly important for people living in the past.

[aufkrawall]

The difference is huge, went from unusable to much faster than X11. I might actually start using it now

Some extra Nvidia fixes are still required for kwin/shell (at least if you don't want a too glitchy experience).
Also the Nvidia Wayland/KMS driver is still missing a ton of features: No night light/GPU gamma ramps, no VRR, no custom EDID, nvidia-settings functionality crippled on xwayland, no mailbox vsync mode for games etc...

[bug77]

AMD and Intel on Linux are using mesa. Mesa has a lot of polling that bipassing the X11/Wayland protocol by using different features in drm/dri layer in the Linux/freebsd... kernel and also mesa uses a few different parts of the wayland protcol to say compositor notify me of change instead of polling the compositor all the time. Yes the way nvidia has implemented their GBM stuff does a lot more polling over Wayland protocol. So its not that that polling at the hardware is faster or slower its more how much polling you attempt to shove though the Wayland protocol if problem appears or not.

Please note there are different bugs in gstreamer that poll wayland heavily as well and this was also causing issues as well with amd and intel gpus as noted in the kde issue/bug with the QT Wayland being the way it was.

So lack of optimisation on the Nvidia side of their GBM code and goof ups in the gstreamer code that exposed this problem with QtWayland. Of course this does not justify having the single thread for everything. Yes this very much the same as the single threaded input of X11 x.org server of old where it worked until you really pushed it then it does not. Multi threading this removes the problem or at least means you have to push a insane amount harder to cause the problem to appear.

Ah, thanks for that. Makes a lot of sense.

[mdedetrich]

AMD and Intel on Linux are using mesa. Mesa has a lot of polling that bipassing the X11/Wayland protocol by using different features in drm/dri layer in the Linux/freebsd... kernel and also mesa uses a few different parts of the wayland protcol to say compositor notify me of change instead of polling the compositor all the time. Yes the way nvidia has implemented their GBM stuff does a lot more polling over Wayland protocol. So its not that that polling at the hardware is faster or slower its more how much polling you attempt to shove though the Wayland protocol if problem appears or not.

Please note there are different bugs in gstreamer that poll wayland heavily as well and this was also causing issues as well with amd and intel gpus as noted in the kde issue/bug with the QT Wayland being the way it was.

So lack of optimisation on the Nvidia side of their GBM code and goof ups in the gstreamer code that exposed this problem with QtWayland. Of course this does not justify having the single thread for everything. Yes this very much the same as the single threaded input of X11 x.org server of old where it worked until you really pushed it then it does not. Multi threading this removes the problem or at least means you have to push a insane amount harder to cause the problem to appear.

Well for starters regardless of how many events are sent this handling should always be in a separate thread, it's like programming for dummies when it comes to GUI because this also reduces average latency/variability (hell in backed systems where I work we do the same thing).

I mean it would be curious to figure out why NVidia is sending more events and what type. If it's just sending the same events more often because of accuracy reasons then there is no point in blaming Nvidia for this and KWin even in the worst case can just drop events via sampling.

On the other hand if we are dealing with a case of duplicate events when it shouldn't be, that's a problem NVidia should fix.

[oiaohm]

I mean it would be curious to figure out why NVidia is sending more events and what type. If it's just sending the same events more often because of accuracy reasons then there is no point in blaming Nvidia for this and KWin even in the worst case can just drop events via sampling.

Its is not this case that its for accuracy reasons.

On the other hand if we are dealing with a case of duplicate events when it shouldn't be, that's a problem NVidia should fix.

Or this case.

Mesa has ways of querying information that does not depend on X11 or Wayland protocol that Nvidia does not have equals to yet.