Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by Iksf View Post
    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.

    Leave a comment:


  • Iksf
    replied
    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.

    Leave a comment:


  • pracedru
    replied
    Originally posted by abu_shawarib View Post

    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

    Leave a comment:


  • abu_shawarib
    replied
    Originally posted by pracedru View Post

    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mdedetrich View Post
    Can you posting things that you don't understand please? Pretty much the entire main developers of the Linux graphics stack that matter disagree with you, including people from AMD, Intel and NVidia. The only issue is one of prioritisation and effort.
    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..

    So how do we tie implicit and explicit sync together? Let userspace extract and set fences itself, of course! The new API, which should be in Linux 5.20, adds two new ioctls on dma-buf file descriptors which allow userspace to extract and insert fences directly. In userspace, these dma fences are represented by sync files. A sync file wraps a dma fence which turns it into a file descriptor that can be passed around by userspace and waited on via poll(). The first ioctl extracts all of the fences from a dma-buf's reservation object and returns them to userspace as a single sync file. It takes a flags parameter which lets you specify whether you expect to read the data in the dma-buf, write it, or both. If you specify read-only, the returned sync file will only contain write fences but if you specify write or read-write, the returned sync file will wait on all implicit sync fences currently in the reservation object. The second ioctl allows userspace to add a sync file to the reservation object. It also takes read/write flags to allow you to control whether the newly added fence is considered a write fence or only a read fence.​
    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.


    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.
    Last edited by oiaohm; 02 February 2023, 01:56 AM.

    Leave a comment:


  • pracedru
    replied
    Originally posted by abu_shawarib View Post

    My experience is the opposite.
    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.

    Leave a comment:


  • qarium
    replied
    Originally posted by make_adobe_on_Linux! View Post
    Imagine if these modern "software engineers" built bridges. They would never be feature complete and they'd have huge round abouts on them that you cannot exit until some security issue with the passenger or car is resolved. "Feature complete" does not exist in their vocabulary. Anyone using Ubuntu deserves a bad experience; they chose their engineering tools and designs based on peer pressure or fads or bribes. Software is made by people, if it has issues, then those issues were in the people first. Debian, Arch, and Mint can do everything better than Ubuntu - depending upon your needs. Yet Ubuntu is pushed in the "FOSS media" at every opportunity.
    Ubuntu is in fact Microsoft and they spend a lot of money to push their poison into the FOSS community

    i have news from hell about this for you:



    yes i know the Rotten.com article about Bill Gates is so old school like the internet 20-25 years ago.
    at that time rotten.com was the most censored website on the internet and it was the only website who did in fact speak the truth about bill gates and microsoft.


    Leave a comment:


  • mdedetrich
    replied
    Originally posted by oiaohm View Post

    This is contains a few flawed ideas.
    https://www.collabora.com/news-and-b...-gap-on-linux/
    implicit sync is how opengl works by standard.

    Glamor is opengl based. Nvidia opengl implementation is busted just happens to be Glamor is one of the items that shows that Nvidia opengl implementation is not to specification. Its not the only item by the way.

    https://gitlab.freedesktop.org/mesa/...requests/17009

    The correct solution to the opengl problem might be simply stop using Nvidia opengl libraries instead use Zink ones that are able to provide implict sync on top of explicit sync only Vulcan drivers.

    mdedetrick you also need to look into Linux kernel mode. Linux DRM kernel mode implicit sync for AMD and Intel are both implemented on top of explicit sync. Yes these wrappers show that rewriting the complete driver is not required.

    Yes mdedetrick there are old opengl games that don't run on modern day Nvidia Opengl under Linux that do run on mesa and closed source AMD opengl.

    The claim the implicit sync problem is restricted to wayland/glamor disregards Valve funded developer on Zink having to add implicit sync support for games because different opengl games need implicit sync to work as well.

    Most wayland compositors are written using egl and yes to be 100 percent to egl specifications implicit sync is meant to work correctly. Clean explicit sync compositor would have to be using vulkan as it graphics.

    Yes since Windows Vista Nvidia had broken opengl implementation that depends on application dependent work around being loaded to get around the implicit sync problem. Yes this does come with the problem if you try to run a old opengl game that that depends on implicit sync that Nvidia has not included work around code in driver it fails when it should no.
    Can you posting things that you don't understand please? Pretty much the entire main developers of the Linux graphics stack that matter disagree with you, including people from AMD, Intel and NVidia. The only issue is one of prioritisation and effort.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mdedetrich View Post
    The explicit sync is one of the main underlying issues why NVidia's driver is not running at full performance on Wayland. However the claim that AMD is giving up 10% for not using explicit sync isn't entirely true, its more explicit than that.

    The core problem is that NVidia's driver doesn't work with implicit sync, it hasn't for years (ever since Windows Vista) and due to current limitations with the Linux GPU stack, NVidia understandably does not what to recode their entire driver to add in implicit sync just for Wayland especially considering that explicit sync is the superior solution (and AMD/Intel have stated this as well).

    So if the Linux graphics stack implemented explicit sync properly all the way through and AMD had explicit sync support, it might gain some trivial performance in games but for NVidia it would massively glose the gap between X11 and Wayland
    This is contains a few flawed ideas.
    https://www.collabora.com/news-and-b...-gap-on-linux/
    implicit sync is how opengl works by standard.

    Glamor is opengl based. Nvidia opengl implementation is busted just happens to be Glamor is one of the items that shows that Nvidia opengl implementation is not to specification. Its not the only item by the way.

    https://gitlab.freedesktop.org/mesa/...requests/17009

    The correct solution to the opengl problem might be simply stop using Nvidia opengl libraries instead use Zink ones that are able to provide implict sync on top of explicit sync only Vulcan drivers.

    mdedetrick you also need to look into Linux kernel mode. Linux DRM kernel mode implicit sync for AMD and Intel are both implemented on top of explicit sync. Yes these wrappers show that rewriting the complete driver is not required.

    Yes mdedetrick there are old opengl games that don't run on modern day Nvidia Opengl under Linux that do run on mesa and closed source AMD opengl.

    The claim the implicit sync problem is restricted to wayland/glamor disregards Valve funded developer on Zink having to add implicit sync support for games because different opengl games need implicit sync to work as well.

    Most wayland compositors are written using egl and yes to be 100 percent to egl specifications implicit sync is meant to work correctly. Clean explicit sync compositor would have to be using vulkan as it graphics.

    Yes since Windows Vista Nvidia had broken opengl implementation that depends on application dependent work around being loaded to get around the implicit sync problem. Yes this does come with the problem if you try to run a old opengl game that that depends on implicit sync that Nvidia has not included work around code in driver it fails when it should no.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by jeisom View Post
    A bunch of the nvidia side were about a 10% difference in favor of X11. I wonder if that is because of explicit sync in their X11 driver. If it were would that mean the amd side is giving up 10% by not using explicit sync yet?
    The explicit sync is one of the main underlying issues why NVidia's driver is not running at full performance on Wayland. However the claim that AMD is giving up 10% for not using explicit sync isn't entirely true, its more explicit than that.

    The core problem is that NVidia's driver doesn't work with implicit sync, it hasn't for years (ever since Windows Vista) and due to current limitations with the Linux GPU stack, NVidia understandably does not what to recode their entire driver to add in implicit sync just for Wayland especially considering that explicit sync is the superior solution (and AMD/Intel have stated this as well).

    So if the Linux graphics stack implemented explicit sync properly all the way through and AMD had explicit sync support, it might gain some trivial performance in games but for NVidia it would massively glose the gap between X11 and Wayland

    https://gitlab.freedesktop.org/xorg/...7#note_1525466 and https://gitlab.freedesktop.org/xorg/...7#note_1358617 is a good summary of the current problem.
    Last edited by mdedetrich; 01 February 2023, 09:56 AM.

    Leave a comment:

Working...
X