Ubuntu 21.04 - X.Org vs. Wayland Linux Gaming Performance

[birdie]

As you obviously don't know, EVERY major OS works this way.

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

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

https://en.wikipedia.org/wiki/Window...SurfaceFlinger

Under Windows/X.org applications 1) can continue to run without the compositor 2) you can continue to work with them without the compositor 3) most extra features, systray, desktop grabbing/casting, RDP/MSTC, drag and drop do not require the compositor to be running

So, sorry, you're full of crap and basically lying.

Under Wayland you kill the compositor and everything DIES.

[oiaohm]

Under Windows/X.org applications 1) can continue to run without the compositor 2) you can continue to work with them without the compositor 3) most extra features, systray, desktop grabbing/casting, RDP/MSTC, drag and drop do not require the compositor to be running

So, sorry, you're full of crap and basically lying.

Under Wayland you kill the compositor and everything DIES.

This is you being wrong. The system tray under Wayland is done by a dbus protocol. So the compositor can in theory die and that keep on working if that has been implemented as a ind-pendant process. There are cases with different X11 windows managers/compositors out there were the systray is not independent to the compositor or windows manager. Most of the extra features under wayland are implemented over dbus so its optional for those to be build into the compositor.

Applications under Wayland can choose if they die when the compositor goes away or if they keep on running until new compositor starts.

https://bugreports.qt.io/browse/QTBUG-85631 this bug here. Applications can choose when a compositor goes away to crash, exit or wait with wayland. Problem here toolkits for Wayland are choosing to exit when compositor stops not because Wayland protocol says they have to. Why this is has nothing to-do with Wayland has everything to-do eglstreams.

eglstreams has a horrible property that when compositor stops everything the compositor allocated goes away. So keeping on running after a compositor has stopped and restarted is not possible with the Nvidia eglstreams. Now lets look at the GBM of mesa. GBM is per process so compositor goes away the allocations on the GPU for applications remain. So application can keep on rendering and working with the GPU with GBM while the Wayland compositor is down if they choose to.

If Nvidia finally support proper per process allocations on the gpu with their DMA BUF support this will allow toolkits to move from exist when noticed the wayland compositor has gone away to wait for a time out before going away so allowing a compositor to be restarted or changed without disrupting application state.

The reality here you don't need a X11 server to allow applications to continue to run without a compositor. We do need GPU drivers not to sabotage applications that decide to keep on running without a compositor. Yes historic Nvidia drivers under X11 with compiz had the same problem that you would stop compiz and all your applications using opengl would start segfaulting because the GPU buffers had pulled the disappearing act so this is not a protocol problem this is a driver problem coming from one particular vendor then working way up the complete stack.

[Azrael5]

We know why Nvidia was doing what they were doing. Its market segmentation. The features wayland compositor developers are after with GBMand DMABHUF wants with applications having their own individual allocations with security will allow splitting consumer gpu between multi end users with security. Nvidia with glstreams wanted to keep the X11 status que of a shared buffer stack so no security. So you wanted to split a GPU between many users with security you would have to buy the higher end cards with Nvidia.

Same with Nvidia making windows drivers that would intentionally break when they detected a VM.

Its not that Nvidia was boycotting Linux users they were wanting to restrict the functionality of their cards so they could charge Linux and Windows users more money to have particular features when the cheaper cards had all the performance those users in fact need. Company greed can be a pain in the ass.

That's the reason I'll switch to AMD video cards. And by the way, Physx is now an open standards, so all hardware manufacturers and open source graphical developers as well can adopt it. I'm curious if mesa developers have been interested in apply physx on MESA drivers.
I'm one of the owner of the first Physx cards sold by Ageia (the company subsequently acquired by Nvidia).

[birdie]

This is you being wrong. The system tray under Wayland is done by a dbus protocol. So the compositor can in theory die and that keep on working if that has been implemented as a ind-pendant process. There are cases with different X11 windows managers/compositors out there were the systray is not independent to the compositor or windows manager. Most of the extra features under wayland are implemented over dbus so its optional for those to be build into the compositor.

Applications under Wayland can choose if they die when the compositor goes away or if they keep on running until new compositor starts.

https://bugreports.qt.io/browse/QTBUG-85631 this bug here. Applications can choose when a compositor goes away to crash, exit or wait with wayland. Problem here toolkits for Wayland are choosing to exit when compositor stops not because Wayland protocol says they have to. Why this is has nothing to-do with Wayland has everything to-do eglstreams.

eglstreams has a horrible property that when compositor stops everything the compositor allocated goes away. So keeping on running after a compositor has stopped and restarted is not possible with the Nvidia eglstreams. Now lets look at the GBM of mesa. GBM is per process so compositor goes away the allocations on the GPU for applications remain. So application can keep on rendering and working with the GPU with GBM while the Wayland compositor is down if they choose to.

If Nvidia finally support proper per process allocations on the gpu with their DMA BUF support this will allow toolkits to move from exist when noticed the wayland compositor has gone away to wait for a time out before going away so allowing a compositor to be restarted or changed without disrupting application state.

The reality here you don't need a X11 server to allow applications to continue to run without a compositor. We do need GPU drivers not to sabotage applications that decide to keep on running without a compositor. Yes historic Nvidia drivers under X11 with compiz had the same problem that you would stop compiz and all your applications using opengl would start segfaulting because the GPU buffers had pulled the disappearing act so this is not a protocol problem this is a driver problem coming from one particular vendor then working way up the complete stack.

OK, I was wrong about the goddamn systray, but you continue with your unabated lying.

Show me a single wayland compositor, which when dies, doesn't bring all the applications down with it. Are there any? None? Well, bugger off with your projections and ideas. In X.org/Windows I can kill my display manager a million times over and everything will work, under your "brilliantly" designed Wayland everything is hanging by the thin thread.

And what about all those APIs which each poor Wayland compositor has to implement? And then user space applications have to support the zoo of differently implemented basic bloody APIs available under all other sanely designed OSes? Why doesn't this madness exist under X.org or Windows? I'll tell you why, your brilliant Wayland designers decided Wayland is just a half-assed protocol which necessitates the implementation of basic bloody features on top of it.

Which again brings us back to the fact which I've repeated ad neaseum now, Wayland is a complete clusterfiasco for minor projects which don't want to write a metric ton of code to support it. And then your effing reference implementation which is Weston has glaring bugs and missing features (e.g. no task bar) right effing now. We're now more than a decade into Wayland development. Now that I've seen your ramblings without being logged on and I'm back to BL'ing you 'cause I don't need total crap like "Applications can choose when a compositor goes away to crash, exit or wait with wayland" instead of arguments. This is not implemented in any shape or form and I'm not even sure you're not BS'ing me right now because you're the only person under the Sun who has claimed that, so, stop, ok? You're a great Wayland theorist, while I'm a poor practician who sees crap for what it is.

Oh, and all the Wayland compositors currently have different ways of setting them up, for crap's sake!! Monitor configuration, input and language configuration, etc. etc. etc. Again an idiotic zoo no one needs.

Let's stick to the known facts. I admit I was wrong about the effing systray, yet, you see, not entirely, since once a Wayland compositor is down, all the running applications are down, so even though technically the systray is implemented via D-BUS or whatever and kinda sorta alive, if there are no applications running, there's no effing systray!

I will continue to avoid this disaster until Wayland developers get their act together and implement something akin to the Xorg server - something which provides rich APIs, and delegates compositors to shiny window decorations, effects, etc. like it's done in all decent reliable operating systems.

I've avoided the use of the F word this time around because I don't want trigger happy moderators to delete the post just because I have lots of haters here.

[oiaohm]

Show me a single wayland compositor, which when dies, doesn't bring all the applications down with it. Are there any? None? Well, bugger off with your projections and ideas. In X.org/Windows I can kill my display manager a million times over and everything will work, under your "brilliantly" designed Wayland everything is hanging by the thin thread.

Sorry different points in X.org X11 bare metal history it has been stop the windows manager or the compositor and everything stops. This is due to driver defects. The reality is wayland compositors are the same. It take quire white before X11 windows managers restarted with X11 server was not playing a game of loto.

And what about all those APIs which each poor Wayland compositor has to implement? And then user space applications have to support the zoo of differently implemented basic bloody APIs available under all other sanely designed OSes? Why doesn't this madness exist under X.org or Windows? I'll tell you why, your brilliant Wayland designers decided Wayland is just a half-assed protocol which necessitates the implementation of basic bloody features on top of it.

X11 protocol is a zoo of insanity remember the Xprint stuff that was printer over X11 protocol. The reality is the modernday X11 bare metal you use in fact implements less than 1/4 of what is written in the X11 protocol. Yes 1/2 were removed by a process of intel developer who was lead of X11 bare metal breaking feature if no one notice removing it. Yes the 1/4 were never implemented in x.org version of the x11 server. Yes X11 applications have to support a zoo. Like there are 4 different ways to-do copy paste under X11 protocol current X11 bare metal and Xwayland support total in the X11 protocol is 10 ways to-do copy paste.

The reality Wayland is in fact less of a half assed protocol than X11.

https://www.phoronix.com/forums/forum/software/desktop-linux/1223572-gnome-s-mutter-40-alpha-released-with-big-improvements?p=1223977#post1223977

Yes this old post covers some of how badly half assed the current contained bare metal X11 protocol copy paste is. This goes on for many features. This does explain why many toolkits on X11 end up rendering by opengl instead of using native X11 protocol.

Let's stick to the known facts. I admit I was wrong about the effing systray, yet, you see, not entirely, since once a Wayland compositor is down, all the running applications are down, so even though technically the systray is implemented via D-BUS or whatever and kinda sorta alive, if there are no applications running, there's no effing systray!

This is not 100 percent true development versions of KDE wayland compositor have contained compositor restart. Yes that is where the compositor goes down and restarts and the applications stay up. Barrier is this is limited most to development builds of KDE because once you mess with eglstreams you have to stop when the compositor does to make sure you don't cause a segment fault and even more data loss because the applications did not shutdown cleanly.

The reality here the system tray and other parts with wayland have been designed to use dbus on the theory that the wayland compositor will be able to be restarted. Problem we need the video drivers to-do that always. So that toolkits don't have to include the bail when wayland compositor goes away and restarts.

The reality here birdie if X11 protocol was working correctly as designed you should be able kill the X11 server and restart it without application dieing as well. There is a historic driver issue here that need fixing. Not just hey lets just run a server to mask over a driver design fault for the next 30 years.

The bad point here after the nvidia drivers are fixed we are going to need a wayland version of https://xpra.org/ . The Wayland compositor going down stoping Xwayland there could still be a X11 application using the modern dbus systemtray still connected because its behind xpra.

Reality here X11 server is broken in this point and is also broken due to bad drivers. The toolkit developers work around this with hey X11 server goes away lets just terminate the application as well.

birdie you keep on talking about the windows manager and compositor restart. History of X11 server the X11 compositor has not always been restratable without killing all opengl applications. The x11 server is not restartable without killing all applications not because the X11 protocol says that has to happen due to bad drivers that is what end up coded in toolkits.

This is something that should have been fixed over 30 years ago. We should have been able to restart X11 server and keep all our applications for over 3 decades now.

[birdie]

@oiaohm

I don't hear you dude!

Broken outdated X.org works perfectly for me right now and I'm not afraid to lose the running applications, in fact I don't remember an X.org session crashing on me for the past ten years.

Modern proper Wayland 1) has crashed on me in less than ten minutes of using it under God-bestowed Intel graphics 2) Doesn't allow to swap compositors on the fly 3) Has numerous critical bugs in Fedora 34 (which are not Fedora specific as Fedora out of all Linux distros just like Slack has stopped heavily patching source packages).

Again, I'll try Wayland in Fedora 35 or 36 or when Wayland developers remove their ears out of their arseholes and write a graphical server which implements the basic desktop features and makes compositors largely redundant and irrelevant. I want a single configuration (monitor, input, keyboard layout, acceleration) for all Wayland sessions, I don't want to choose apps based on which compositor they support - this is fucking madness.

I don't want to hear why Wayland could be better. It must be better or bugger off.

Over and out.

[oiaohm]

@Again, I'll try Wayland in Fedora 35 or 36 or when Wayland developers remove their ears out of their arseholes and write a graphical server which implements the basic desktop features and makes compositors largely redundant and irrelevant..

This is a no. This means the 30 year old+ graphics driver bug remains in place. This means parties like Nvidia will write their driver to only work with that server.

There is a need for the fragmentation. We need graphics drivers to be wayland compositor/X11 server netural. There have been cases where distributions have had to delay deploying updated x11 bare metal because Nvidia need to release a new driver because they were hooked so deeply in.

birdie like or not there is a need for better security and drivers to be implemented supporting that security. The reason why you cannot swap compositors on the fly is a security that you ignore. The ablity to random probe the GPU allocated buffers to access internal buffers of other applications.

The reality is you want another broken like X11 server solution the reality is the enterprise developers are not going fun this. With there desktop requirements of security this does not pass go.

I want a single configuration (monitor, input, keyboard layout, acceleration) for all Wayland sessions

This has its own problem. HTPC systems where you change from being a PC to being a entertainment system and back. Some of those setups have been implementing hacks to have more than 1 configuration per X11 session. Yes input, keyboard layout and acceleration can require to be different per session.

I don't want to choose apps based on which compositor they support

This already happens under X11 bare metal with the way the X11 compositor is implemented that different applications break when you use particular X11 compositors. Yes there are commercial X11 applications that require particular version of X11 server as well.

Wayland protocol include means to stack compositors on top of compositors due to the past commercial applications problems with X11.

birdie you see your problems but totally have your head in the sand for the problems the Wayland developers being enterprise developers have run into.

Yes nvidia drivers being locked to X11 server results in not being able to stack X11 servers. Yes one of the objectives of XWayland is in fact to be able to run multi versions of XWayland possible versions customised for particular trouble making apps that don't update because of the past problems that you are head in sand about.

[dpeterc]

X11 protocol is a zoo of insanity remember the Xprint stuff that was printer over X11 protocol. The reality is the modernday X11 bare metal you use in fact implements less than 1/4 of what is written in the X11 protocol. Yes 1/2 were removed by a process of intel developer who was lead of X11 bare metal breaking feature if no one notice removing it. Yes the 1/4 were never implemented in x.org version of the x11 server.

You have picked a bad example. The basic idea of Xprint extension is sound, it allows rendering with X11 toolkit at printer native resolution, with saving in Postscript, PC5, Bitmap... Basically, it allows off-screen rendering.
It is an EXTENSION, and every X11 application should use XQueryExtension() to see if it can use it or not. If the extension is not present, the application should work without it.
For various reasons, Xprint extension never got popular, and in was subsequently removed from X.org.
So this proves just the opposite, how X11 has grown in functionality with extensions, but also that it can be slim, since rarely used extensions can be removed.
Not the zoo of insanity that you describe.

[Azrael5]

You have picked a bad example. The basic idea of Xprint extension is sound, it allows rendering with X11 toolkit at printer native resolution, with saving in Postscript, PC5, Bitmap... Basically, it allows off-screen rendering.
It is an EXTENSION, and every X11 application should use XQueryExtension() to see if it can use it or not. If the extension is not present, the application should work without it.
For various reasons, Xprint extension never got popular, and in was subsequently removed from X.org.
So this proves just the opposite, how X11 has grown in functionality with extensions, but also that it can be slim, since rarely used extensions can be removed.
Not the zoo of insanity that you describe.

An example is not sufficient to determine a statistically tendance. It's an error of salience. Question is that a good progress has difficult to be implemented because hardware manufacturers don't support it as it deserves, or that the transitional phase aimed to adequate the several desktop graphical environments is problematic. The first problem can be faced excluding the non-compliant hardware from the progress, such as Ubuntu has made avoiding that Wayland environment be applied when an Nvidia card runs the system, the second matter deals with the various linux team programmers which are involved in the transitional phase.

[oiaohm]

You have picked a bad example. The basic idea of Xprint extension is sound, it allows rendering with X11 toolkit at printer native resolution, with saving in Postscript, PC5, Bitmap... Basically, it allows off-screen rendering.

You just wrote a pile of mistakes.
https://gitlab.freedesktop.org/xorg/xserver-xprint yes xprint was removed from the X.org server mainline and made into its own server build. Why there are horrible legacy applications that need it even today. Yes its buggy with modern X11 servers.

Do notice you are needing to build libXfont different to normal to use xprint. This now means you need a font server that is not part of current day X11 server as well....

It is an EXTENSION, and every X11 application should use XQueryExtension() to see if it can use it or not. If the extension is not present, the application should work without it.

This is not true no matter how much we wish. X11 applications that need xprint will do a XQueryExtension() to see if the extension is present or not and if it not present not run at all.

Xprint is a lot better example than you are giving it credit to the zoo problem. Xprint is one for extentions that demos why we need a proper defined server stacking that works with opengl acceleration. Yes in time there will be needs for custom versions of XWayland so particular programs work. Like a custom version of XWayland to support Xprint with font server enabled only has to have that overhead for the applications that really need it.

So this proves just the opposite, how X11 has grown in functionality with extensions, but also that it can be slim, since rarely used extensions can be removed.
Not the zoo of insanity that you describe.

It is a zoo of broken. Because Nvidia being the biggest problem until recently has not allowed you to use more than 1 X11 server with opengl acceleration working properly. Yes this is partly why multi seat has not taken off as much as it could have because you have 2 X11 servers on 1 Nvidia GPU the result has been only 1 is getting GPU time or both crash depending on the Nvidia driver version. The recent change is the second one gets lower performance and what is the second one is basically picked random-ally not even statically based on start order.

Yes wayland design to have extentions is also to allow it to be slimmed down. The X11 developers behind wayland had learnt from X11 that you need to be able to provide full feature next to slimmed down this means you need to be able to run more than 1 Wayland compositors/X11 servers so stacking is a important feature. This leads us to the Nvidia teeth pulling process.

Yes Wayland with XWayland on top forces Nvidia to have to support a stacked solution if they want Wayland support going forwards because people need XWayland for some legacy applications.

The first problem can be faced excluding the non-compliant hardware from the progress, such as Ubuntu has made avoiding that Wayland environment be applied when an Nvidia card runs the system, the second matter deals with the various linux team programmers which are involved in the transitional phase.

The problem here we cannot exclude Nvidia cards for ever because support X11 and Wayland is resulting in applications maintainers having to-do proper work. Nvidia offering for X11 has not really been up to standard. XNest or other X11 stack options most people have failed to notice you use Nvidia you drop back to software rendering.

There has been a need for a show down with Nvidia for not providing Linux and Unix and BSD users with the functionality they should have for a very long time.