KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

[oiaohm]

The Wayland graphics acceleration is provided by Glamor, which has no 3D acceleration capabilities, hence the dire 3D performance compared to X applications and compositors leveraging GLX.

This is so wrong its not funny.

https://lists.x.org/archives/xorg-devel/2014-April/042117.html

Glamor even for DRI2 has had 3d acceleration support. The 3d acceleration code is mostly just moving around buffers.

Remember I pointed out I did not have problem with AMD or Intel same way. AMD and Intel have full GBM/DMABUF support from their opengl drivers so work with glamor with indirect GLX.

Indirect GLX does not work with Xwayland because the Glamor rendering engine is not compatible with our EGL implementation.

Yes Nvidia own documentation you are going to take a hit. Remember Zink can run Xwayland interest question what does glxgears look like on Nvidia when you use Zink instead of Nvidia opengl. So use Nvidia vulkan and don't use Nvidia opengl at all because it too big of a broken mess.

Zink lets you get xnest and Xephyr working under bare metal X11 as well with proper acceleration with Nvidia as well.

Its fun Nvidia vulkan code has the items for handling DMABUF/GBM well but Nvidia EGL code does not. Most likely the fast way to fix the Nvidia driver is for Nvidia to drop their opengl section completely and use zink instead.

The reality is Nvidia driver is broken. The issue you are talking about don't not apply to anyone using Intel and AMD. Also with zink new support for Xwayland most likely does not have to apply to Nvidia users either as long as they are willing to stop using the opengl part of their Nvidia drivers.

Yes Zink was not a option 5 months ago.

On the input side of things, wayland prefers some weird, perverted form of "security" over input latency. That results often in numerous very nasty bugs when that superfluous (because permissions is not a job for a display compositor) layer of security doesnt behave as it should, and best case degraded performance over Xorg-server which doesnt waste time trying decide if an application running on its compositor is allowed to receive keyboard and mouse input.

There is a performance overhead to what X11 is doing. . Think about all the processes you are wasting cpu time on that are not going to process the input doing the X11 way. KGlobalAccel was added for KDE 4 in 2007 before Wayland exists for X11 because there is a problem here. The xorg-server input stack has problem with costing too much processing time. Worst input latency due to producing too many copies of input.

[mSparks]

The 3d acceleration code is mostly just moving around buffers.

Via the CPU... = not hardware accelerated

There is a performance overhead to what X11 is doing. . Think about all the processes you are wasting cpu time on that are not going to process the input doing the X11 way. KGlobalAccel was added for KDE 4 in 2007 before Wayland exists for X11 because there is a problem here. The xorg-server input stack has problem with costing too much processing time. Worst input latency due to producing too many copies of input.

measured in nano seconds, to waylands milliseconds.
result =

https://www.reddit.com/r/kde/comments/1335gj5/mouse_feels_laggy_and_slow_on_wayland_compared_to/

How are you going to blame nvidia for that on an intel laptop with no nvidia card?

[oiaohm]

Via the CPU... = not hardware accelerated

Not the case. GPU cannot manage it own memory by design. So what glamor does is the CPU part of gpu hardware acceleration basiclaly setting up the output buffer for the application gpu operations to draw to so it will be displayed. These operations even the X11 Nvidia closed source driver does in CPU in userspace.

Most likely problem here is Nvidia driver is not providing the EGL functions of glamor to do the task. This is broken driver.

[QUOTE=mSparks;n1413682How are you going to blame nvidia for that on an intel laptop with no nvidia card?[/QUOTE]

There was no measurement there. Yes there is a intel gpu clocking issue. Also what were the measurements on that intel laptop.

observed it for a while on 5.26 AFAIR and early 6.0 kernels on fedora. Booted an LTS 5.10 and it went away. Some weeks later it was also gone on the stock kernel

You did not read all what you quoted right.

AMDGPU has had a performance issue with enabling fifo.

https://gitlab.freedesktop.org/drm/amd/-/issues/2516#note_2119750

Good read. GPU scheduler that is part of the GPU driver can screw things over badly by allowing the applications GPU requests to block out everything else.

There have been Intel and AMD driver scheduler issues causing performance problems. Some of these are clearly weed out wayland/xwayland combination. Different applications under X11 will generate the same problems.

Are the intel and AMD issues here also broken drivers yes. But you can get intel and amd drivers that don't show the problem or set configuration so the problem goes away.

Find some random place to quote that has not been worked though to what the real problem is does not mean you have found a Wayland issue. Yes this intel is Wayland exposed driver issue again not that the Wayland protocol causes it.

[mSparks]

There was no measurement there. Yes there is a intel gpu clocking issue. Also what were the measurements on that intel laptop.

"visible lagging" is anything more than 15ms latency.

[oiaohm]

"visible lagging" is anything more than 15ms latency.

No measurements. So no clue what the problem is. Visible lagging is not restricted to Wayland.

https://bbs.archlinux.org/viewtopic.php?id=282548

Here a NVIDIA using using x.org X11 server having visible lag problems and Wayland is working fine in there setup and its Nvidia. I could pull intel and amd ones like this as well.

mSparks does not mater the GPU vendor AMD/Intel/Nvidia I can pick reported issues that make them all look bad with either X11 or Wayland or Windows and this includes all vendors and all platforms at once. Also you have AMD and Intel messing around with CPU scheduler to attempt to get more performance this does not always work out.

Visible lagging with X11 and Wayland is very much what driver bug did I find today. Most of the time it GPU driver bug of some form other times is a CPU scheduler bug. Of course Nvidia driver implementation being garbage gives you more bugs to find due to not implemented features or incorrectly implemented features.

None of the fully investigated performance bugs are leading back to causes that are Wayland unique. Results is at times Wayland just makes the existing faults simpler to trigger.

mSparks you claims about performance issues with Wayland are "Confirmation bias". You are expecting Wayland to perform poorly so you never looked if the same kinds of poor performance are turning up on the X11 side as well. Fact the same problems are turning up on both X11 and Wayland side says that we have driver issues. Yes using Nvidia hardware due to the known broken parts of the Nvidia drivers you are going to see more faults under Wayland than X11 but that does not mean the faults with Nvidia under X11 showing defective drivers causing performance problems is not there.

Yes this all round driver problem is one of the reasons why valve is funding zink and dxvk and vkd3d. Its also the reason why valve pushed heavily for the layer system in vulkan so that parties like valve could put corrective shims over vendor vulkan implementations when they had screwed it up.

https://www.khronos.org/news/members/valve-software

Yes it really simple to forget valve was a member of khronos back in 2012 before Vulkan came a thing in 2016 and had direct input in the final design of Vulkan even that they are not a GPU vendor because they are one of the largest users.

[mSparks]

No measurements. So no clue what the problem is. Visible lagging is not restricted to Wayland.

greater than 16ms latency by design is exclusive to wayland. Xorg-server doesn't introduce 16ms latency between an input signal and the application receiving it. Wayland does.

until wayland disaggregates input compositing from video compositing (i.e. never), it will suffer from visible lagging (i.e. always).
This line:

In wayland the compositor is the display server. We transfer the control of KMS and evdev to the compositor.

in

https://wayland.freedesktop.org/architecture.html

see also

https://en.wikipedia.org/wiki/Evdev

[oiaohm]

until wayland disaggregates input compositing from video compositing (i.e. never), it will suffer from visible lagging (i.e. always).

What if you are completely wrong on the never for many years now.

https://www.phoronix.com/news/GNOME-40-Separate-Input-Thread

Wayland protocol does not mandate that the video compositing and the input compositing be in the same thread. Weston did this a while ago.

And not all versions of x.org has input in a split of thread either in fact you can intentionally built x.org X11 server bare metal without this feature.

https://wayland.freedesktop.org/architecture.html

In wayland the compositor is the display server. We transfer the control of KMS and evdev to the compositor.

It does not say that the KMS and evdev have to be processed in the same thread.

https://blog.vladzahorodnii.com/2020/12/10/compositing-scheduling-in-kwin-past-now-and-future/

Currently, compositing infrastructure in KWin is heavily influenced by the X11 requirements, e.g. there is only one compositing clock, compositing is throttled to the lowest refresh rate, etc. Besides that, incorrect assumptions were made about the behavior of glXSwapBuffers() and eglSwapBuffers(), unfortunately, which result in frame drops and other related issues. With the ongoing Wayland improvements, we hope to fix the aforementioned issues.

Yes the KMS when you have multi monitors does not have to have all the video compositing a single thread either but we have Wayland compositors doing this performance costing action.

Lot of this is stripping out legacy X11 ideas out of Wayland compositors. Wayland compositors can have more threads than X11 compositor can.

This does explain why having X11 compositor loaded cripples performance so much. The very problem you just accused wayland every X11 compositor suffers from. The catch here not all Wayland compositors do in fact it coming highly uncommon for Wayland compositors to have this problem. Some wayland compositors are more complete in the multi threading process than others.

Yes wayland compositor is valid to have multi threads.

https://en.wikipedia.org/wiki/Evdev

Also you need to notice the nightmare in what you quoted.

For Weston/Wayland compositor, the stack would look like this: kernel → libevdev → libinput → Wayland compositor → Wayland client
Since version 1.16 the xorg-xserver obtained support for libinput: kernel → libevdev → libinput → xf86-input-libinput → X server → X client

O bugger me your bare metal X11 has more processing over head for input since 1.16 than Wayland compositors will have. This is kind of why Xwayland has same input latency as bare metal X11 server when everything is working correctly.

Reason is libinput has all code to deal with all the quirky input devices out there is why direct X11 x.org bare metal to evdev was basically dropped.

[mSparks]

O bugger me your bare metal X11 has more processing over head for input since 1.16 than Wayland compositors will have. This is kind of why Xwayland has same input latency as bare metal X11 server when everything is working correctly.

You still don't get the problem here.
games and other latency sensitive applications talk directly to devices through /dev/input/ no middleware. xf86-input-libinput is a helper for transmitting mouse and keyboard etc input over a network.

However on wayland only the wayland compositor can do this, and it does so slowly you can see the mouse cursor lag behind as you move it..

[oiaohm]

games and other latency sensitive applications talk directly to devices through /dev/input/ no middleware. xf86-input-libinput is a helper for transmitting mouse and keyboard etc input over a network.

Someone is two steps behind. Be it wayland compositor or X11 bare metal server when you hit a device locked in /dev/input the party you have to argue with is libinput.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/110

Yes this is proposed for wayland is going to be in up coming meeting.

However on wayland only the wayland compositor can do this, and it does so slowly you can see the mouse cursor lag behind as you move it..

Is what you wrote true. The answer is no it not.

https://github.com/snyball/hawck

Like this macro tool a lot of games have been using under X11 a root privilege application to get access to evdev because X11 baremetal xf86-input-libinput has claimed the evdev device and not giving it back.

The hard reality here is the current Wayland compositors are no worse than the bare metal X11 server when it comes to blocking raw input device access. Of course if inputfd gets merged and implemented in Wayland compositors this will be area where Wayland compositors will be better than bare metal X11 servers.

Here a good question if the evdev blockage is the same why does game perform differently. Answers not wayland answer surprise is xwayland partly. xwayland does not have the raw /dev/evdev being used by default. So the handler root handler application games have for getting direct evdev access fail.

Is it possible by add on have xwayland tell the application raw /dev/evdev to let direct input work yes it is and gamescope does this. How does gamescope when layered on top of another wayland compositor locate the evdev to report. Simple look at the evdev files open by the compositor it stacked under.

Also valve developers tell us(yes they know absolute) that 99% of games don't do use raw evdev. A game running under wine/proton surprise does not use raw evdev. Its a percent of Linux native ported games that use raw evdev even then it a small percentage.

The there biggest problems that cause mouse issues with Wayland.
1) Wayland Compositor not having input processing in it own thread.
2) Hardware mouse cursor not working right this is a driver bug. Yes this one things go bad if you enabled hwcursor under x11 bare metal as well. There is environment var to disable plane that causes this. Yes Nvidia hardware is also known for advertising hwcursor support when it does not work. Wayland compositors default with this on does cause a few problems. Between stutter to slow mouse movement to no mouse cursor at all because hardware accelerated mouse cursor is not working correctly when the GPU driver advertised it support it.
3)GPU and CPU scheduler issues.

Notice something none of the issue have anything todo with the Wayland protocol.

Yes nice to have evdev direct access in the Wayland protocol so for the corner cases that use/need feature not to have a root process that can access everything but getting this feature for 99% issues is not going to change a thing because 99%+ of software people think have this problem don't use raw evdev in the first place.

mSparks basically you are critically wrong again.

[mSparks]

Someone is two steps behind. Be it wayland compositor or X11 bare metal server when you hit a device locked in /dev/input the party you have to argue with is libinput.

Nope, developers cannot talk to libinput when using wayland, this is intentional, because "keyloggers".

Yes this is proposed for wayland is going to be in up coming meeting.

do let me know how a proposal to allow keyloggers on wayland works out, you seem optimistic.

and gamescope does this.

KDE is switching to gamescope for their wayland compositor? that's pretty big news.
Or are you advocating abandoning KDE and everyone switching to SteamOS?

Is it possible by add on have xwayland

xwayland adds even more latency, and only supports applications that use the X11 protocol for device io.