X.Org vs. Wayland Linux Gaming Performance For NVIDIA GeForce + AMD Radeon In Early 2023

[abu_shawarib]

How so?
I have an Nvidia GTX 1060 GPU and running it on XOrg makes it stutter just moving a window where as on Wayland it is buttery smooth.

Windows movements are indeed are much smoother, but other things like pop-up video and 3d games can be laggy, especially when not in exclusive full screen. There are occasional bugs and glitches all around that don't exist in X11 to the same degree. The instability introduced outweighs the benefits for me. Maybe in a year or two things will be ironed out.

[pracedru]

Windows movements are indeed are much smoother, but other things like pop-up video and 3d games can be laggy, especially when not in exclusive full screen. There are occasional bugs and glitches all around that don't exist in X11 to the same degree. The instability introduced outweighs the benefits for me. Maybe in a year or two things will be ironed out.

Sorry but I don't have any of those issues on fedora 37

[Iksf]

I was originally very pro-wayland and very excited first reading about it on this website like 10+ years ago. But its just not delivered, and huge amount of time has been invested from so many projects to support it (and still there is work to do even now). If we'd never had wayland we'd have approximately as shit a display server anyway and all that time could have been spent on anything else.

At this point I don't really have an opinion on which to use, which is imo a big fail from wayland. It's just a bit of a bust in terms of expectations even if the thing mostly works now at long last.

[oiaohm]

I was originally very pro-wayland and very excited first reading about it on this website like 10+ years ago. But its just not delivered, and huge amount of time has been invested from so many projects to support it (and still there is work to do even now). If we'd never had wayland we'd have approximately as shit a display server anyway and all that time could have been spent on anything else.

At this point I don't really have an opinion on which to use, which is imo a big fail from wayland. It's just a bit of a bust in terms of expectations even if the thing mostly works now at long last.

There is something missed it took 8 years to decide to start Wayland as X11 developers tried to find any possible way to fix X11 protocol because the workload to move away from X11 protocol was going to be massive undertaking.

Lot of ways early Wayland marketing was way too optimistic.

[qarium]

https://www.collabora.com/news-and-b...-gap-on-linux/
No mdedetrich read the above AMD/Intel and Collabora kernel developers don't agree with what you wrote either..
https://www.kernel.org/doc/html/late...sync_file.html Yes that import and export sync is documented here.
Yes that says 5.20 but that really Linux kernel 6.0 released 2 October 2022 yes was merged in kernel 6.0.
This bit is important. Linux kernel developers have gone the route of Implicit and explicit sync both working with each other. Yes the reason why you can extract the kernel kernel implicit sync explicit fences to user space and have it work in explicit sync is that its implemented on explicit sync.
mdedetrich yes the AMD and Intel developers believe that the core operations of graphics should be explicit sync but they don't agree that implicit sync should be rendered non functional.
You have to remember the Linus Torvalds rule here "We do not break user-space". Since the Linux kernel DRM subsystem historically has supported implicit sync it has to remain supporting implicit sync.
The hard reality here Nvidia explicit sync only is breach of Linux kernel development rules and makes their opengl implementation non conforming that causes Valve problems even on windows one of the reason why Valve funded porting zink to windows.
Now also remember you need to pass explicit sync fences between processes when you have Wayland compositor.
Yes the proposal that has been accepted into the Linux kernel is both implicit sync and explicit sync will play nice with each other.
Older protocols like X11 and Opengl and Linux kernel framebuffer have written into them that items should be implicit synced.

https://www.kernel.org/doc/html/v5.0/gpu/drm-kms.html

Helper to setup the plane_state fence in case it is not set yet. By using this drivers doesn’t need to worry if the user choose implicit or explicit fencing.
Notice something here. There is a stack of wrapper functions in the Linux kernel in many different places that mainline graphics drivers don't have to care if the sync items are used in implicit or explicit by userspace other parts of the kernel.
mdedetrich Nvidia path is zero implicit sync support that does not have the agreement of those making Wayland compositors, those wanting to run old application or in fact not backed by AMD or Intel developers. Yes Intel and AMD and Nvidia developers agree the core of graphics drivers should be explicit sync to avoid over sync issues but Intel and AMD developers are not attempting to force everyone to change over to explicit sync. No implicit sync is break legacy applications. Yes Intel and AMD linux kernel developers agree on keeping implicit sync on top of explicit sync for legacy applications.
Yes Linux kernel having proper way to use implicit sync and explicit sync with each other without shooting each other in foot is 2022 new thing. Linux does not have to go the same route as Windows.
Nvidia attempting to completely drop implicit sync is really like windows dropping win16 support then intel developer expecting Linux kernel to also remove win16 support. Remember Wine still has win16 support for legacy applications and that is supported by the Linux kernel because of the same Linus Torvalds rule.

it reallly sounds sane for now but i think this will hurt linux over long time.

because of this lag of leadershipment from people like linus torvalds this stupid rule to not break userspace will end up in more any more legacy cruft.

we maybe don't like it but windows profits from the fact that they drop legacy cruft like win16 or implicit sync... and other stuff.

at some point linux will accumulate more and more of this old legacy cruft in the "Linus Torvalds rule here "We do not break user-space"" space.

to be honest on the graphic/gpu side linux does not feel competive to windows we amd gpu users have no driver GUi like the people on windows
and also we have big legacy problem with vulkan extensions for example polaris cards and soon vega cards will have the same problem that amd does no longer develop new vulkan extensions for the old cards the result is that these old cards can not run the vulkan DKVK/Proton layers at the same time on windows in DirectX 9/11/12 everything works well and the people have no legacy problem... on the linux side people with polaris cards are forced to buy new cards or else they can no longer play their games. sad story but true. proton of valve does in fact expect an RDNA2 GPU like the steam deck and they push new vulkan extensions. old cards does not get the extenions and planet obsolecense push these people in front of a running bus.

linux on the gpu side does not feel competive to windows and with more Linus Torvalds rules this situation will become even worst over time.

[oiaohm]

because of this lag of leadershipment from people like linus torvalds this stupid rule to not break userspace will end up in more any more legacy cruft.

https://www.phoronix.com/news/Linux-5.5-Kills-SYSCTL-SYSCALL

Do not break userspace does not mean never remove legacy cruft from kernel. There is leadership.

we maybe don't like it but windows profits from the fact that they drop legacy cruft like win16 or implicit sync... and other stuff.

https://microsoft.github.io/DirectX-Specs/d3d/D3D12EnhancedBarriers.html

How badly wrong you are. Read this carefully. Yes Windows Direct X 12 still has implicit sync. There are lots of cases Microsoft obeys the rule of "do not break userspace" yes Nvidia windows drivers have not had to implement implicit sync but Microsoft goes and puts a wrapper on top with direct X that does implicit sync so legacy applications work.

Nvidia with its Linux drivers and userspace has been highly adverse to having wrapper placed on top.

Nvidia if you want to provide you own made opengl libraries its your responsibility to follow the specification this includes providing Implicit sync. With Nvidia open sourcing their driver for newer cards these have the possibility of using the generic wrappers in the kernel to provide implicit sync where its required in the code base of the Linux kernel and for the syscalls that require implicit sync. So not the code they have to take care of.

mdedetrich claimed a false agreement. There is a big difference between just providing a driver and providing complete stack.

to be honest on the graphic/gpu side linux does not feel competive to windows we amd gpu users have no driver GUi like the people on windows
and also we have big legacy problem with vulkan extensions for example polaris cards and soon vega cards will have the same problem that amd does no longer develop new vulkan extensions for the old cards the result is that these old cards can not run the vulkan DKVK/Proton layers at the same time on windows in DirectX 9/11/12 everything works well and the people have no legacy problem.

Direct X 9 implicit sync.
Direct X 11 implicit sync and explicit sync in userspace ABI.
Direct X 12 implicit sync and explicit sync in userspace ABI.
Microsoft is obeying rule of "do not break user space" here with wrappers putting back legacy functionality. Nvidia linux opengl not having functional implicit sync and saying hey developers update your program so those work this would mean that Direct X 9 and 11 would not work under Windows of Microsoft followed the same rules.

DKVK not working with older cards because some Vulkan extension is missing does not line up with the windows wrapper implementation you can find this with hardware feature levels and exposed functionality. Direct X 12 only requires a Direct X 11 driver yes Direct X 12 falls back to software implementation of some functionality.

https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/device_simulation_layer.html

The Vulkan problem is something else. Vulkan is design that extensions can be added by third parties who are not the hardware vendor by software emulation. The vulkan layers to add newer features to older cards have not been developed at this stage. Microsoft direct X does have cpu emulation layers so newer applications calling newer DX functions the GPU does not support still work and older applications using older functionality like implicit sync the graphics drivers no longer support still work. Yes the do not break userspace stuff.

So the DKVK not working on older cards on Linux is a 3 way tango between driver vendors, Lack of developers working on vulkan functianality emulation layers and DKVK developers.

Do be aware that Valve does want to use DKVK on windows as well to get around some applications that depend on directx removed quirks. Yes the vulkan problem of not getting new extensions for old cards effects windows users as well. Yes this includes the lack of cpu emulation layers to add different functions to old cards..

Vulkan is designed to be better for this than Opengl. But better designed still require developers to be funded to put the time in.

no driver GUi << This one is interesting. Turns out most of that has been a single russia developer under Windows. Linux world has not been luck enough to have a developer make driver GUI then vendors deciding to pay for that developers time.

[qarium]

https://www.phoronix.com/news/Linux-...SYSCTL-SYSCALL
Do not break userspace does not mean never remove legacy cruft from kernel. There is leadership.

of course there is leadershipment but you write about the failure we have right now at the bottom of your post about how vulkan means planet obsolescence hits users hard on linux and on windows there is zero impact and windows users on old hardware have much more luck to play games.
so the leadershipment in the kernel does not compensate for the lag of leadershipment in the vulkan driver space.

https://microsoft.github.io/DirectX-...dBarriers.html
How badly wrong you are. Read this carefully. Yes Windows Direct X 12 still has implicit sync. There are lots of cases Microsoft obeys the rule of "do not break userspace" yes Nvidia windows drivers have not had to implement implicit sync but Microsoft goes and puts a wrapper on top with direct X that does implicit sync so legacy applications work.
Nvidia with its Linux drivers and userspace has been highly adverse to having wrapper placed on top.
Nvidia if you want to provide you own made opengl libraries its your responsibility to follow the specification this includes providing Implicit sync. With Nvidia open sourcing their driver for newer cards these have the possibility of using the generic wrappers in the kernel to provide implicit sync where its required in the code base of the Linux kernel and for the syscalls that require implicit sync. So not the code they have to take care of.
mdedetrich claimed a false agreement. There is a big difference between just providing a driver and providing complete stack.
Direct X 9 implicit sync.
Direct X 11 implicit sync and explicit sync in userspace ABI.
Direct X 12 implicit sync and explicit sync in userspace ABI.
Microsoft is obeying rule of "do not break user space" here with wrappers putting back legacy functionality. Nvidia linux opengl not having functional implicit sync and saying hey developers update your program so those work this would mean that Direct X 9 and 11 would not work under Windows of Microsoft followed the same rules.

this honestly really sounds like Nvidia does sapotage Linux and also Nvidia does sapotage OpenGL

I dropped my last nvidia card in 2007 i know for a long time this nvidia people are evil maniacs ...

DKVK not working with older cards because some Vulkan extension is missing does not line up with the windows wrapper implementation you can find this with hardware feature levels and exposed functionality. Direct X 12 only requires a Direct X 11 driver yes Direct X 12 falls back to software implementation of some functionality.
https://vulkan.lunarg.com/doc/view/1...ion_layer.html
The Vulkan problem is something else. Vulkan is design that extensions can be added by third parties who are not the hardware vendor by software emulation. The vulkan layers to add newer features to older cards have not been developed at this stage. Microsoft direct X does have cpu emulation layers so newer applications calling newer DX functions the GPU does not support still work and older applications using older functionality like implicit sync the graphics drivers no longer support still work. Yes the do not break userspace stuff.
So the DKVK not working on older cards on Linux is a 3 way tango between driver vendors, Lack of developers working on vulkan functianality emulation layers and DKVK developers.
Do be aware that Valve does want to use DKVK on windows as well to get around some applications that depend on directx removed quirks. Yes the vulkan problem of not getting new extensions for old cards effects windows users as well. Yes this includes the lack of cpu emulation layers to add different functions to old cards..
Vulkan is designed to be better for this than Opengl. But better designed still require developers to be funded to put the time in.
no driver GUi << This one is interesting. Turns out most of that has been a single russia developer under Windows. Linux world has not been luck enough to have a developer make driver GUI then vendors deciding to pay for that developers time.

look its all a failure of linux and people don't care what is the reason why it is a failure

for example i pulled a amd HD6860 out of my mothers computer and replaced it with an intel arc a380 ok do not talk about the intel card talk about the amd hd6870 just to make an example on windows people who play older games Dx9 and dx11 games are just fine with this card and there are windows 10 drivers ok there are no windows 11 drivers but most people i know are happy with windows 10 ok now compare this to linux the same card AMD hd6870 is a hell of a nightmare on linux the dx9 games do not work the dx11 games do not work maybe the openGL games work but very slow.

now say lets behind this poison AMD hd 6000 series of VLIW4D/5D and now talk about the amd HD7000 series

its a dx12 card and on windows dx9 games work dx11 games work and dx12 games work...

the same amd hd7000 card on linux is a nightmare come true because of the lag of vulkan extensions of this old driver to run dx9/dx11/dx12 in proton is a nightmare even if you switch from RadeonSI kernel part manually to AMDGPU kernel part to get the vulkan support but one vulkan extensions not supported and you are out of luck,.,

and this goes up to AMD rx480/RX590 all these polaris cards people report some vulkan extensions make sure Valve proton does no longer work.

i have a vega64 and i know 2023 will be the last year of support for vega and then i am in the vulkan extension hell as well.

at the same time people on windows use vega64 without any problems.

in the past linux was known for anti-planed-obsolecense caracteristic but today with vulkan on linux you are forced to buy new GPU card every 5-6 years or else stuff will break and stuff will not work...

now tell me where is the leadershipment there ? its a big fat failure.

[oiaohm]

this honestly really sounds like Nvidia does sapotage Linux and also Nvidia does sapotage OpenGL

That exactly how it looks.

for example i pulled a amd HD6860 out of my mothers computer and replaced it with an intel arc a380 ok do not talk about the intel card talk about the amd hd6870 just to make an example on windows people who play older games Dx9 and dx11 games are just fine with this card and there are windows 10 drivers ok there are no windows 11 drivers but most people i know are happy with windows 10 ok now compare this to linux the same card AMD hd6870 is a hell of a nightmare on linux the dx9 games do not work the dx11 games do not work maybe the openGL games work but very slow.

Wine dx to opengl conversion is not pain free. I guess you tried with steam. Yes having to set PROTON_USE_WINED3D=1 in "Set Launch Options" in every game you want to run by the Linux steam client so it works with a card this old is really not user-friendly.

So yes dx9-11 applications should have been to made work at least as good as they do in wine. But its absolutely not userfriendly and not high performing. Do know a lot that end up using windows version steam in wine with galluim-nine on hardware that old. Linux steam client does not support using galluim-nine natively at all and the opengl back in for proton is a pure pain to use.

Of course wine and proton support is not perfect.

the same amd hd7000 card on linux is a nightmare come true because of the lag of vulkan extensions of this old driver to run dx9/dx11/dx12 in proton is a nightmare even if you switch from RadeonSI kernel part manually to AMDGPU kernel part to get the vulkan support but one vulkan extensions not supported and you are out of luck,.,

This is kind of valve again. Why is vulkan extensions missing total failure with dx9 and dx11 games. There is the WINED3D fall back that use opengl Steam does not make this option easy.

proton works with dxvk(vulkan) or wined3d(opengl) for dx8-11. So the fact you were not finding this option this is a steam client userfriendly problem.

Vulkan extensions missing causing dxvk to fail completely that does fall on dxvk also still falls on valve with steam.

https://github.com/doitsujin/dxvk/wiki/Driver-support

Notice dxvk developer keeps a old version recommended for Vulkan 1.1 Ok not going to perform as well as the new version but if you don't have the hardware feature to get the better performance.

People using wine older hardware end up using older dxvk. Yes of course steam default proton is not your only option either.

i have a vega64 and i know 2023 will be the last year of support for vega and then i am in the vulkan extension hell as well.

To be correct you don't know. The vulkan issue with proton is a 3 way tango. DXVK, hardware vendors and missing third parties.

now tell me where is the leadershipment there ? its a big fat failure.

Lot of people are not aware that you can force games to use opengl backend under steam. Lot of people are not aware that you can force steam to use older versions of proton or third party generated versions of proton with things changed like locked to old dxvk version so works with old cards.

Of course there is still lack of developers for vulkan compatibility layers. As in vulkan layers to allow newer vulkan extensions to work on older cards.

Its more where are the resources and cases of poor user friendliness by steam. Yes game does not run vulkan error no clue that opengl backend is option or that different version of proton is option.

Yes steam could detect if they wanted to what GPU you have and set default proton version to match. Or valve could decide to fund vulkan layer developers.

Lot of what you wrote sounds to me case of hitting Valve horrible steam interface and getting a very false appearance of what the problem is. Yes many a day its good thing that the developers of the Linux steam client are not close to me or I might be done for verbal assault cursing them over some of these interface problems..

[ssokolow]

because of this lag of leadershipment from people like linus torvalds this stupid rule to not break userspace will end up in more any more legacy cruft.

[...]

we maybe don't like it but windows profits from the fact that they drop legacy cruft like win16 or implicit sync... and other stuff.

[...]to be honest on the graphic/gpu side linux does not feel competive to windows we amd gpu users have no driver GUi like the people on windows
and also we have big legacy problem with vulkan extensions for example polaris cards and soon vega cards will have the same problem that amd does no longer develop new vulkan extensions for the old cards the result is that these old cards can not run the vulkan DKVK/Proton layers at the same time on windows in DirectX 9/11/12 everything works well and the people have no legacy problem... on the linux side people with polaris cards are forced to buy new cards or else they can no longer play their games. sad story but true. proton of valve does in fact expect an RDNA2 GPU like the steam deck and they push new vulkan extensions. old cards does not get the extenions and planet obsolecense push these people in front of a running bus.

linux on the gpu side does not feel competive to windows and with more Linus Torvalds rules this situation will become even worst over time.

Microsoft lives by the "Don't break userspace" rule even more than Linux does and it's a big part of why they maintain a 95%+ market share. Windows 3.1 bent over backwards to be compatible with MS-DOS, Windows 95 bent over backwards to be compatible with both of them, and Windows XP bent over backwards to be compatible with Win9x-lineage stuff. That's why they have a massive testing team and Windows comes with gigabytes of DLLs in WinSxS (Their analogue to Flatpak runtimes) and a ton of built-in "If application X, pretend to still have old bug Y" (eg. Win9x famously had an "If SimCity for DOS, allow application to keep using memory after free()-ing it") rules.

In fact, that's one of people's biggest complaints about Linux. That userspace doesn't follow the "don't break userspace" rule to provide a reliable base platform beyond the raw kernel syscalls that applications rarely interact with directly.

Microsoft didn't drop Win16 support until Win64, at which point they still left 32-bit installs of Windows remain compatible for users with such needs. They only dropped 32-bit Windows this year for Windows 11, and there are still older version of Windows with 32-bit releases that haven't gone out of support yet... and, if they had decided to port the Win16 thunking layer to 64-bit kernels, they'd probably still be supporting it now with no plans to actively drop it.

The fact that AMD doesn't write a driver GUI and doesn't backport Vulkan extensions has nothing to do with "Don't break userspace". Heck, windows is more aggressive about dropping hardware support, what with how many models of printer and scanner work on modern Linux but not modern Windows.

[qarium]

That exactly how it looks.
Wine dx to opengl conversion is not pain free. I guess you tried with steam. Yes having to set PROTON_USE_WINED3D=1 in "Set Launch Options" in every game you want to run by the Linux steam client so it works with a card this old is really not user-friendly.
So yes dx9-11 applications should have been to made work at least as good as they do in wine. But its absolutely not userfriendly and not high performing. Do know a lot that end up using windows version steam in wine with galluim-nine on hardware that old. Linux steam client does not support using galluim-nine natively at all and the opengl back in for proton is a pure pain to use.
Of course wine and proton support is not perfect.

my friend i used wine directX 9-11 to OpenGL conversion many years before proton/DXVK popped up and the performance drop by doing so is very high .... Proton/DXVK you lose maybe 6-7% performance but on DX to OpenGL vonversion you lose 50-60% performance
this is to high for these old hardware.
just remember it was just an example this card i will give it away for people who use windows. for this old hardware windows performs much better.

i just made an example about how linux is not competive in this GPU space.

This is kind of valve again. Why is vulkan extensions missing total failure with dx9 and dx11 games. There is the WINED3D fall back that use opengl Steam does not make this option easy.
proton works with dxvk(vulkan) or wined3d(opengl) for dx8-11. So the fact you were not finding this option this is a steam client userfriendly problem.
Vulkan extensions missing causing dxvk to fail completely that does fall on dxvk also still falls on valve with steam.

https://github.com/doitsujin/dxvk/wiki/Driver-support

Notice dxvk developer keeps a old version recommended for Vulkan 1.1 Ok not going to perform as well as the new version but if you don't have the hardware feature to get the better performance.
People using wine older hardware end up using older dxvk. Yes of course steam default proton is not your only option either.

again directX to OpenGL is not an option because you lose 50-60% performance and on vulkan/DXVK you only lose 6-7% performance.
and yes it is all a Usability hell and who cause this does not matter at all a steam client userfriendly problem or whatever the result is that linux is a usability nightmare and not competive compared to windows.
and use old DXVK for older hardware even if possible is still a Usability hell and really not the way to go for the people.

if you want any kind of usability you end up buy new gpu card... thats the status we have right now.

and the people who do all the stuff you say are the absolut minority...

To be correct you don't know. The vulkan issue with proton is a 3 way tango. DXVK, hardware vendors and missing third parties.
Lot of people are not aware that you can force games to use opengl backend under steam. Lot of people are not aware that you can force steam to use older versions of proton or third party generated versions of proton with things changed like locked to old dxvk version so works with old cards.
Of course there is still lack of developers for vulkan compatibility layers. As in vulkan layers to allow newer vulkan extensions to work on older cards.
Its more where are the resources and cases of poor user friendliness by steam. Yes game does not run vulkan error no clue that opengl backend is option or that different version of proton is option.
Yes steam could detect if they wanted to what GPU you have and set default proton version to match. Or valve could decide to fund vulkan layer developers.
Lot of what you wrote sounds to me case of hitting Valve horrible steam interface and getting a very false appearance of what the problem is. Yes many a day its good thing that the developers of the Linux steam client are not close to me or I might be done for verbal assault cursing them over some of these interface problems..

you are absolutly right its a steam/gui problem valve should make these options visible in the guy to choose dx to openGL or older DXVK for older hardware or write a autodetect mechanism.

and i am in the sam boot as you for "verval assault cursing them" i want linux to win the battle agaist microsoft but with this status we will not win this.

is very easy to detect why valve dont do this: "Or valve could decide to fund vulkan layer developers." because the steam deck is RDNA2 and don't have this problem. right now they only care about RDNA2 or newer... and even vega or RDNA1 users are out of the luck right now.

problem is valve has no big reason to fix the "Valve horrible steam interface" problem outside of the steam deck ...