Revert "video: Decide Wayland over X11 (take 2)"

Description

This reverts commit f9f7db4

Wayland has a myriad of unresolved considerations relating to floor suspension blocking presentation and the FIFO (vsync) implementation being principally broken ensuing in diminished GPU-sure performance.

That is to now not voice “we might per chance moreover quiet fix FIFO in Mesa/other drivers,” however rather that it is some distance fully unfixable with out a further protocol, on this case fifo-v11.

With out this protocol, vkQueuePresent or glSwapBuffers need to stall for the ‘physique’ callback after presenting an image. The correct motive we are in a position to come by away with this on SteamOS is as a consequence of Gamescope implements what is if truth be told fifo-v1 and we use that there.

The opposite facet is floor suspension — an extraordinarily the same lisp to the above wrt the physique callback being outmoded in that formulation and blocking. If the SDL window is obscured, vkQueuePresent will block in FIFO, which games assuredly enact NOT love. Right here’s solved by the aggregate of fifo-v1 and commit-timing-v1.

There’s never such a thing as a aid to games and moderate capabilities preferring Wayland over X11 — finest severe performance and unusability regressions soft now.
Thus, we need to revert this commerce until fifo-v1 and commit-timing-v1 are released and now not now not up to in a stable free up for major compositors.

If we enact this, we’re assuredly accepting these considerations are unfixable for the following ten years (SDL4). Having this as the default in SDL3 (which is now not if truth be told being outmoded yet!) is valuable for signaling to other stakeholders that we if truth be told enact want to come by solutions in place of dwelling for detected considerations.

Reproduction hyperlink

Contributor

Author

If we enact this, we’re assuredly accepting these considerations are unfixable for the following ten years (SDL4).

We’re fully accepting they’re unfixable soft now sure, as a consequence of they’re — however likely now not for the following ten years.

We can flip the default later in SDL3’s lifecycle, and even in accordance with whether or now not fifo-v1 and commit-timing are uncovered within the wl_registry.

is valuable for signaling to other stakeholders that we if truth be told enact want to come by solutions in place of dwelling for detected considerations.

SDL is now not your instrument for “signaling to stakeholders” about what is valuable. It’s an valid library outmoded by real builders and customers!

You are suggesting we enact those customers and builders a disservice by forcing an principally broken default onto them purely for your individual ideological causes.

It’s if truth be told valuable as a developer is to be pragmatic and separate your individual desires from what if truth be told advantages your customers/customers.

If we enact this, we’re assuredly accepting these considerations are unfixable for the following ten years (SDL4). Having this as the default in SDL3 (which is now not if truth be told being outmoded yet!) is valuable for signaling to other stakeholders that we if truth be told enact want to come by solutions in place of dwelling for detected considerations.

The considerations pointed at by Joshua are traditional, having broken FIFO by default on Wayland methodology transport a native sport with it is some distance exclusively now not viable and would secure linux as a complete eye less intriguing to a sport developer. I construct now not judge what you suggest is charge this possibility and neither is constructing a astronomical wise device back for customers of existing games that might per chance come by ported to SDL3.
Whereas the considerations talked by Joshua are very technical in nature and it is some distance always nontrivial for of us experiencing it to search out out it is some distance due to Wayland, “SDL might per chance now not switch to Wayland until right here’s in place of dwelling” IMHO sends a a lot clearer signal.

Must this be a device back list (speaking relating to the explicit considerations, and choices for what to enact about them) in want to a pull seek files from (already selecting a particular option apparently with out prior dialogue from individuals furious by this)…?

Must this be a device back list (speaking relating to the explicit considerations, and choices for what to enact about them) in want to a pull seek files from (already selecting a particular option apparently with out prior dialogue from individuals furious by this)…?

IMHO it would now not secure a lot sense as the lisp exists completely open air of SDL, it has to enact with how Vulkan and GL calls behave when working under native Wayland and since, now not now not up to within the case of Vulkan, those are calls are made by the user straight away I if truth be told doubt there might per chance even be a unusual solution. In other words right here’s a Wayland WSI lisp and now not an SDL lisp.

Provided that we soft released the SDL 3.0 preview, I’m leaning in the direction of ensuring players and builders own a soft ride. We can commerce this default all over again at some point.

@Joshua-Ashton, can you add a code observation mercurial describing the considerations and the criteria for making Wayland the default all over again?

@icculus, @Kontrabant, enact you’ve got any concerns before we merge this?

IMHO it would now not secure a lot sense as the lisp exists completely open air of SDL

It makes as a lot sense (or extra) than a SDL pull seek files from, I judge. 🙂

I if truth be told doubt there might per chance even be a unusual solution.

I have not heard anybody weigh in on how long it might per chance moreover take for those considerations to be resolved in Wayland and in drivers, and whether or now not their timelines would omit SDL3’s plump free up or now not.

There’s never such a thing as a aid to games and moderate capabilities preferring Wayland over X11

In my thought I’m having a eye forward to improved DPI scale make stronger.

Excluding for the FIFO wayland protocol (that will most likely be utilized every time anybody wants), I construct now not own any references of upstream discussions related to those considerations which point out the FIFO protocol or the same things. In my thought, I did now not own any thought the protocol used to be so valuable until today.

@Joshua-Ashton I realize your thought and conclusion, however on condition that SDL3 has now not yet been released, enact you judge any resolution on this can moreover be deferred until very rapidly before the free up?

I’m coming from a unusual attitude, of scientific capabilities and distributors of proprietary apps, and loads of enact now not desire or can now not make stronger Wayland due to its boundaries. And that can by no methodology commerce unless someone makes some noise about it, so I of direction own a pair of protocols proposed to repair the raised considerations. One hectic thing is that the affected app distributors enact now not desire to engage with Wayland protocol discussions, so there’s no weight or urgency within the encourage of the protocol additions.
Vendors soft paper over the Wayland considerations with impolite workarounds or by simply persevering with to utilize X11.
And I thing that is the thing the place @Conan-Kudo is soft.

So, per chance this resolution might per chance even be deferred for now and as a substitute the SDL carrying out might per chance moreover throw its weight within the encourage of the respective Wayland protocols so they come by utilized sooner? If nothing occurs within the required timeframe and if at SDL3’s scheduled free up time the considerations quiet persist, you might per chance maybe moreover clearly switch encourage to X11. But then the carrying out has tried its finest to collaborate and fix considerations on the source, in want to papering over them too early.

This reverts commit f9f7db4

Wayland has a myriad of unresolved problems regarding surface suspension
blocking presentation and the FIFO (vsync) implementation being
fundamentally broken leading to reduced GPU-bound performance.

That is not to say "we should fix FIFO in Mesa/other drivers," but rather
that it is completely unfixable without an additional protocol, in this
case fifo-v1[1].

Without this protocol, vkQueuePresent or glSwapBuffers *must* stall for
the 'frame' callback after presenting an image.
The only reason we can get away with this on SteamOS is because
Gamescope implements what is essentially fifo-v1 and we use that there.

The other side is surface suspension -- a very similar issue to the
above wrt the frame callback being used in that way and blocking.
If the SDL window is obscured, vkQueuePresent *will* block in FIFO,
which games typically do NOT like. This is solved by the combination of
fifo-v1 and commit-timing-v1.

There is no advantage to games and average applications preferring
Wayland over X11 -- only severe performance and unusability regressions
right now.
Thus, we must revert this change until fifo-v1 and commit-timing-v1 are
released and at least in a stable release for major compositors.

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256

Rolling encourage soft methodology you are working through XWayland as a substitute, which has the same underlying considerations with things love throttling occluded dwelling windows, and loses things love scaled framebuffer make stronger vs working natively.

The correct real formulation to absolutely steer determined of right here’s to bustle a native X session until the considerations are addressed.

Reproduction hyperlink

Contributor

Author

@Joshua-Ashton, can you add a code observation mercurial describing why X11 is most traditional when on hand?

Executed.

Excluding for the FIFO wayland protocol (that will most likely be utilized every time anybody wants), I construct now not own any references of upstream discussions related to those considerations which point out the FIFO protocol or the same things. In my thought, I did now not own any thought the protocol used to be so valuable until today.

These forms of discussions re. fifo own soft been Mesa builders speaking together over IRC or someplace else out-of-band.

I have been making a astronomical deal out of now not now not up to floor suspension for a pair of years now, however Wayland progress is sluggish. :/

No now not up to we’re getting somewhere now… I’m hoping. 🙂

@Joshua-Ashton I realize your thought and conclusion, however on condition that SDL3 has now not yet been released, enact you judge any resolution on this can moreover be deferred until very rapidly before the free up?

The fact of this might occasionally now not commerce with time or before free up.

The soft solution is for us to want Wayland finest if fifo-v1 + commit-timing is on hand — in any other case default to X11.

We can with out disaster take a look at the wl_registry for those, and own two Wayland_bootstrap entries, one for _preferred, one for _fallback (ie. if no X11)

The soft solution is for us to want Wayland finest if fifo-v1 + commit-timing is on hand — in any other case default to X11.

If this PR is now not the soft solution, can you sketch one up that’s (or will most likely be)?

Reproduction hyperlink

Contributor

Author

Rolling encourage soft methodology you are working through XWayland as a substitute, which has the same underlying considerations with things love throttling occluded dwelling windows, and loses things love scaled framebuffer make stronger vs working natively.

XWayland would now not own the lisp wrt. fifo as the Vulkan X11 WSI implementation there can use a presentation thread and put in drive a commit queue on the customer facet. Right here’s now not that you just might per chance maybe moreover agree with within the Wayland WSI because it is some distance ABI that QueuePresent=wl_surface_commit.

Wrt. throttling, that doesn’t happen on XWayland or when using an X11 graphical compositor as every window there becomes CompositeRedirectManual and thus, constantly technically “offscreen” — however they’re quiet unthrottled as a consequence of it tests for that.

When you slay up using X11 with out a compositor, you might per chance be throttled to 1Hz when your window is occluded, alternatively if you’re using a native Wayland window and are occluded, you might per chance by no methodology be in a place of dwelling to secure forward progress the least bit, and your utility will stall forever. Wayland WSI is if truth be told violating the Vulkan forward progress ensures for presentation soft now due to this.

Reproduction hyperlink

Contributor

Author

If this PR is now not the soft solution, can you sketch one up that’s (or will most likely be)?

It’s miles the soft solution until those protocols land in upstream wayland-protocols.

@Joshua-Ashton, can you add a code observation mercurial describing why X11 is most traditional when on hand?

Executed.

Excluding for the FIFO wayland protocol (that will most likely be utilized every time anybody wants), I construct now not own any references of upstream discussions related to those considerations which point out the FIFO protocol or the same things. In my thought, I did now not own any thought the protocol used to be so valuable until today.

These forms of discussions re. fifo own soft been Mesa builders speaking together over IRC or someplace else out-of-band.

I have been making a astronomical deal out of now not now not up to floor suspension for a pair of years now, however Wayland progress is sluggish. :/

No now not up to we’re getting somewhere now… I’m hoping. 🙂

Right here’s likely why things drag on for so long. If the complete discussions are out-of-band in a formulation that other stakeholders (in particular integrators, desktop builders, etc.) have not any visibility, then there will most likely be no motion.

(Certain, I’m attentive to a pair considerations with some stakeholders, however on the complete most of us did now not know one thing until soft now.)

@Joshua-Ashton I realize your thought and conclusion, however on condition that SDL3 has now not yet been released, enact you judge any resolution on this can moreover be deferred until very rapidly before the free up?

The fact of this might occasionally now not commerce with time or before free up.

The soft solution is for us to want Wayland finest if fifo-v1 + commit-timing is on hand — in any other case default to X11.

We can with out disaster take a look at the wl_registry for those, and own two Wayland_bootstrap entries, one for _preferred, one for _fallback (ie. if no X11)

What is the timeline for the SDL 3 free up?

What is the timeline for the SDL 3 free up?

That relies largely on the suggestions on the Preview Launch. Realistically now not shorter than 3 months. We quiet own over 300 considerations within the free up milestone.

Might per chance well we take care of this for a bit of whereas then whereas we are attempting to come by things sorted out within the many upstreams?

@Joshua-Ashton, can you add a code observation mercurial describing why X11 is most traditional when on hand?

Executed.

Excluding for the FIFO wayland protocol (that will most likely be utilized every time anybody wants), I construct now not own any references of upstream discussions related to those considerations which point out the FIFO protocol or the same things. In my thought, I did now not own any thought the protocol used to be so valuable until today.

These forms of discussions re. fifo own soft been Mesa builders speaking together over IRC or someplace else out-of-band.
I have been making a astronomical deal out of now not now not up to floor suspension for a pair of years now, however Wayland progress is sluggish. :/
No now not up to we’re getting somewhere now… I’m hoping. 🙂

Right here’s likely why things drag on for so long. If the complete discussions are out-of-band in a formulation that other stakeholders (in particular integrators, desktop builders, etc.) have not any visibility, then there will most likely be no motion.

(Certain, I’m attentive to a pair considerations with some stakeholders, however on the complete most of us did now not know one thing until soft now.)

@Joshua-Ashton I realize your thought and conclusion, however on condition that SDL3 has now not yet been released, enact you judge any resolution on this can moreover be deferred until very rapidly before the free up?

The fact of this might occasionally now not commerce with time or before free up.
The soft solution is for us to want Wayland finest if fifo-v1 + commit-timing is on hand — in any other case default to X11.
We can with out disaster take a look at the wl_registry for those, and own two Wayland_bootstrap entries, one for _preferred, one for _fallback (ie. if no X11)

What is the timeline for the SDL 3 free up?

The floor suspension dialogue came about partly publicly right here https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/ninety 9

There’s never such a thing as a aid to games and moderate capabilities preferring Wayland over X11

I need to mention right here that this assertion is always now not staunch. Going through Xwayland methodology execrable habits with fractional scaling – with most compositors that methodology diminished resolution within the sport, however even on KWin it causes considerations with a pair of displays which own different scales (on displays with a lower scale you come by an elevated resolution within the sport).

One more device back of Xwayland is that open air of fullscreen, it does a copy of every physique before passing it on to the compositor. It would thus lower performance and prolong latency, especially if the compositor can offload the floor to an overlay plane.

Xwayland can enact finest 8 bits per color as effectively, which is a minor aid for going with native Wayland.

It’s miles mostly charge noting that Xwayland is now not fully proof against the floor suspension lisp either, it throttles dwelling windows that construct now not come by physique callbacks to 1Hz.

There are important considerations with working natively on Wayland, however please let’s now not pretend Xwayland is wide either. There are advantages and disadvantages to every decisions, they assuredly might per chance moreover quiet be weighed against one one more, it be now not soft an glaring substitute for one facet.

Might per chance well we take care of this for a bit of whereas then whereas we are attempting to come by things sorted out within the many upstreams?

Even assuming the protocol used to be one scheme or the other merged and likewise utilized by ample compositors in precisely 3 months (which is rather a lot most now not most likely) I construct now not judge this can moreover reasonably attain stable releases in 3 months? This lisp is thoroughly known AFAIK among of us that work round the gap.

It’s miles the soft solution until those protocols land in upstream wayland-protocols.

I’m a bit of at a loss for words soft now from your messages, I judge this sums things up if I bought it soft?

These performance considerations own an impact on finest a subset of Vulkan setups when Wayland is outmoded (FIFO repeat mode, now not Mailbox or others) and construct now not own an impact on OpenGL since I have not seen it talked about.
There’s now not now not up to at least one stuffed with life merge seek files from for a protocol that can fix a pair of of the considerations you raised, which you linked earlier.
You furthermore mght stated “The fact of this might occasionally now not commerce with time or before free up.” which I construct now not moderately yet given the above merge seek files from and this PR also raising visibility to related individuals.
You own gotten a proposal to secure Wayland most traditional finest if the protocols which kind things are on hand.
The protocols are most likely to be now not finalized so SDL likely need to now not place apart code in for them moderately yet.
But you might per chance maybe moreover quiet secure a draft PR which does that – i.e. the ‘soft thing’.

So I judge having this as a device back dialogue, and making that draft PR seem love soft suggestions. Except I misread one thing?

That is soft hiding the device back I judge, can you detect with out disaster if the compositor has fifov1

It’s miles the soft solution until those protocols land in upstream wayland-protocols.

I’m a bit of at a loss for words soft now from your messages, I judge this sums things up if I bought it soft?

* These performance issues affect only a subset of Vulkan setups when Wayland is used (FIFO present mode, not Mailbox or others) and don't affect OpenGL since I haven't seen it mentioned.

* There's at least one active merge request for a protocol that will fix some of the issues you raised, which you linked earlier.

* You also said "The reality of this will not change with time or before release." which I don't quite yet given the above merge request and this PR also raising visibility to relevant people.

* You have a proposal to make Wayland preferred only if the protocols which fix things are available.

* The protocols are not finalized so SDL _probably_ shouldn't put code in for them quite yet.

* But you could still make a draft PR which does that – i.e. the 'right thing'.

So I judge having this as a device back dialogue, and making that draft PR seem love soft suggestions. Except I misread one thing?

The considerations own an impact on OpenGL as effectively ( extra particularly EGL since that is the api outmoded for presentation )
Any sport on the complete enables the user to select between FIFO and IMMEDIATE (and MAILBOX assuredly)/gl’s the same swap interval so this applies to any sport shipped with SDL
The MR is soft a protocol, a small piece of the puzzle
To examine for the protocol it need to first be finalized and added to the registry or else there might be never such a thing as a protocol to examine for

Reproduction hyperlink

Contributor

Author

@Zamundaaa

It’s miles mostly charge noting that Xwayland is now not fully proof against the floor suspension lisp either, it throttles dwelling windows that construct now not come by physique callbacks to 1Hz.

Doesn’t seem staunch for me on Plasma 6 Wayland, labwc and Gnome — I also construct now not judge wherever in xserver that’d enact that. Everything is CompositeRedirectManual on XWayland, so it need to now not.

@Zamundaaa

It’s miles mostly charge noting that Xwayland is now not fully proof against the floor suspension lisp either, it throttles dwelling windows that construct now not come by physique callbacks to 1Hz.

Doesn’t seem staunch for me on Plasma 6 Wayland, labwc and Gnome — I also construct now not judge wherever in xserver that’d enact that. Everything is CompositeRedirectManual on XWayland, so it need to now not.

Running testsprite (with –vsync) on Gnome + XWayland, it throttles to 1hz for me when the window is occluded with every the GL and Vulkan renderers.

Reproduction hyperlink

Contributor

Author

@Zamundaaa

One more device back of Xwayland is that open air of fullscreen, it does a copy of every physique before passing it on to the compositor. It would thus lower performance and prolong latency, especially if the compositor can offload the floor to an overlay plane.

Right here’s also now not staunch — this finest applies to child dwelling windows that enact now not bear your complete window, and capabilities using XCopyRect, or other XComposite extensions.

Video games and most apps will now not come by a further copy, as they bear your complete window, or own a child window that fills your complete window.

Xwayland can enact finest 8 bits per color as effectively, which is a minor aid for going with native Wayland.

Certain, however that’s an added bonus if truth be told. That is if truth be told one among the key causes the Gamescope WSI layer exists. The opposite regressions are rather traditional and rather outrageous.

10-bit color for your sport is now not if truth be told if truth be told precious if the GPU-sure performance is completely frogged physique-pacing brilliant 😀

Might per chance well we take care of this for a bit of whereas then whereas we are attempting to come by things sorted out within the many upstreams?

Even assuming the protocol used to be one scheme or the other merged and likewise utilized by ample compositors in precisely 3 months (which is rather a lot most now not most likely) I construct now not judge this can moreover reasonably attain stable releases in 3 months? This lisp is thoroughly known AFAIK among of us that work round the gap.

That is counting on the free up cycle of a style of compositors. In theory, we might per chance moreover own an implementation for KWin shipped out in Plasma 6.1 in June. I’m in a position to’t focus on about other desktops and their approach to handling new protocol enablement, though GNOME 47 is due in August/September (which is soft a pair months later).

Doesn’t seem staunch for me on Plasma 6 Wayland, labwc and Gnome — I also construct now not judge wherever in xserver that’d enact that. Everything is CompositeRedirectManual on XWayland, so it need to now not.

It’s this timer: https://gitlab.freedesktop.org/xorg/xserver/-/blob/grasp/hw/xwayland/xwayland-repeat.c?ref_type=heads#L53

I’ve had individuals whinge about it kicking them out of online games, and whereas you place vkcube or glxgears on a unusual digital desktop, you might per chance maybe moreover judge them being updated at 1Hz within the overview (and within the terminal output of glxgears).

Right here’s also now not staunch — this finest applies to child dwelling windows that enact now not bear your complete window, and capabilities using XCopyRect, or other XComposite extensions

Sorry, appears to be like love I’ve misunderstood the Xwayland code, it has different tests than the total code.

Reproduction hyperlink

Contributor

Author

KWin would now not throttle physique callbacks of dwelling windows which might per chance maybe be merely obscured (yet), finest after they’re minimized or on a unusual digital desktop

To examine for the protocol it need to first be finalized and added to the registry or else there might be never such a thing as a protocol to examine for

So as that is the key anguish soft? Not loads the eventual make stronger by compositors?

If the protocol is sorted out that you just might per chance maybe moreover reliably take a look at for it be make stronger at runtime, you might per chance maybe moreover want wayland, in any other case skedaddle along with X?

Reproduction hyperlink

Contributor

Author

So as that is the key anguish soft? Not loads the eventual make stronger by compositors?

If the protocol is sorted out that you just might per chance maybe moreover reliably take a look at for it be make stronger at runtime, you might per chance maybe moreover want wayland, in any other case skedaddle along with X?

Certain, that’s what I’m proposing for us so that you just might per chance add when the protocols are finalized.

Name this a complete shot on the hours of darkness, however: Did the Steam overlay ever come by Wayland floor make stronger added? I’ve now not checked in ages however that might per chance likely be soft to want to secure discussions on this extra thorough; it be one thing if we now own a complete quit-to-quit implementation of an all-Wayland draw and give compositors as a lot files as that you just might per chance maybe moreover agree with in enforcing the protocols, it be one other if Steam soft by no methodology implements for desktop or embedded and SDL chickens out with none real commitment from any inviting party to repair this. We’d soft be encourage at sq. one all over again, which I’m now not if truth be told up for doing a third time in four years(!).

If now not the overlay, and if gamescope does indeed enact this soft, per chance it would secure sense to default to Wayland when gamescope is working, and if it will uncover the protocols early, we are in a position to secure it extra strong to default when the protocols are uncovered, as someone instructed earlier. So long as one thing is occurring that’s honest, however until I judge one thing in writing that claims right here’s going to come by done then it be gripping for me to examine this commerce in soft faith, which for me is soft an automated “no”.

TL;DR: My customers come by soft results with this backend (even on Steam!); unilaterally sweeping others’ effort under the rug as a foremost resort, as a correct of other shareholders’ experiences, doesn’t sit effectively with me with out some if truth be told soft proof that this is now not if truth be told a indolent cop-out.

Did the Steam overlay ever come by Wayland floor make stronger added?

Steam overlay would now not work in wayland-native apps.

Reproduction hyperlink

Contributor

Author

Name this a complete shot on the hours of darkness, however: Did the Steam overlay ever come by Wayland floor make stronger added?

No, it hooks Vulkan, etc soft honest, however there might be never such a thing as a enter on the overlay and Steam Input is now not functional.

For GL apps, it doesn’t work the least bit with Wayland.

Sorting this out with Gamescope would be frosty, using the same stuff we use on Deck for the overlay — especially as we now own the Wayland subsurface backend (which is now not tormented by the same considerations referenced on this MR), however we’re now not at that point yet.