Announcement

Collapse
No announcement yet.

XWayland 24.1 Planned For Release Next Month With Explicit Sync & Other Features

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

  • mSparks
    replied
    Originally posted by oiaohm View Post
    Implicit sync is really good with resource management
    Hmmm, so I agree maybe I came across to strongly against implicit sync.
    Both implicit/explicit have very meaningful differences, pros and cons,

    e.g. it is not a good idea to require applications to have to worry about synchronisation issues, abstracting away those issues / implicit sync is a good thing. race conditions - particularly in graphics are a development nightmare.

    But, afaik, the #1 Pro for explicit sync is performance - which is why from a display server pov, implicit is substandard.

    There is very similar arguments for opengl v vulkan, both have a place, because opengl is and will always be far more development friendly, due to most of the hard work being done by the driver, whereas there is no beating a well written vulkan application for performance - but its much easier to create a badly written, buggy, poorly performing vulkan application than an opengl one.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by anda_skoa View Post
    I would be surprised if that has ever actually been measured.
    Its been measured and its not much. It about 1/3 of the cost of Xwayland in input latency. Gamer for you these minor values count..

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mSparks View Post
    If anything there is NO sync in X11, because one window cannot modify the memory of another window, they can only exchange commands.
    This is not true. XACE provides protections to prevent X11 applications from altering window owning to a different application. Of course people don't have XACE enabled by default.

    The reality the default security of X11 is security by obscurity. Once you go snooping around in X11 lists of resources without XACE loaded you can get up to all kind of trouble.

    Originally posted by mSparks View Post
    implicit/explicit sync only applies when you have something trying to do different things on the same resource at the same time
    To be correct default X11 protocol is explicit sync hidden by security by obscurity with no structures to perform safe explicit sync. Yes the presume you will not go around looking at resource ids and using those resource ids to access and alter items your application did not create is what the X11 protocol is depending on.

    Yes lack of safe and solid sync solution in X11 results in X11 protocol having lots of different cases of race conditions.

    Originally posted by mSparks View Post
    heck, that was the whole "selling point" of wayland we've been fed for the last few years it was implicit sync "every frame is perfect" that you "couldnt do" in X11 (except you could, with vsync).
    To be correct you could not do every frame is perfect with vsync on under X11 all the time. Take x11 2d operations there is no sync to know what is a complete set of 2d operations yes no opengl equal to begin/end so a X11 2d operations application could have a half complete output no sync to refer to so a vsync and output a half done. There is example after example like this mSparks inside X11 protocol. This is why it comes impossible to get rid of tearing completely with X11 and it all due to too many defects in the protocol with areas lacking sync info..

    The new explicit sync support in wayland does not remove implicit sync memory management of Wayland.

    Application under Wayland passes a buffer up to Wayland compositor and the Wayland compositor frees the buffer it received what happens to the buffer the application still has? That right the buffer the application still has remains in existence until the application frees it and the kernel determines no other party is using it.. Yes the reverse is also true with compositor sending something application and the application frees it the compositor keeps it copy until it frees compositor frees it..

    Wayland memory management implicit sync prevents applications rug pulling another application. Yes it possible under x11 to deallocate or alter another application allocated X11 resource at any time.

    Implicit sync is not only for every frame is perfect. Implicit sync is really good with resource management so you don't have one process being able to rug pull the resources out from under a different process. Implicit sync on resource management has very low cost because resource allocation and frees are commonly not on hot paths.​

    In fact you can do every frame is perfect with careful usage of explicit sync. The problem comes doing memory/resource management with explicit sync.

    How can you make sure application executing real true buffer free should be doing the real true buffer free. Remember explicit sync the process is basically standing on it own two feet no third party to check if it right or wrong. Implicit sync you have a third party who can be checking the buffer user count and the like to decide when a buffer should truly be freed.
    Last edited by oiaohm; 15 April 2024, 06:48 AM.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by oiaohm View Post
    Will allow the old faking to work. Please note PCSX was not using window manager rules to fake it. Instead using open window at absolute position to fake it. .
    The customer's applications also make use of this for other scenarios but in this case they needed window manager rules to override the application behavior to ensure consistency.

    In any case not really important. The demo was intended to show an approach that is available with Wayland (custom compositor) that would be a lot of work on X11 (custom display server + custom window manager).

    Originally posted by oiaohm View Post
    PCSX2 being a game thing input latency is a thing. Having input pass though to compositors instead of one they class as a problem.
    I would be surprised if that has ever actually been measured.

    But even if that were a genuine concern it would be far better to address this directly, e.g. having an even queue per sub surface.
    Web browsers need to do this kind of input forwarding as well and could leverage this.

    It is also not unlikely that this kind of set up would become more common now that it is so much easier to accomplish.
    Process separation can be nice for isolation, modularity, stability and scalability.

    Leave a comment:


  • mSparks
    replied
    Originally posted by smitty3268 View Post

    X11 is 100% implicit sync, and always has been. It doesn't sound like you actually understand what explicit sync is about.

    Nvidia works around it by replacing a bunch of X with their own alternative code, by plugging in their x driver. xwayland didn't allow them to replace x anymore with their own private interface, which is why it didn't work for them.
    If anything there is NO sync in X11, because one window cannot modify the memory of another window, they can only exchange commands.

    implicit/explicit sync only applies when you have something trying to do different things on the same resource at the same time - this is where wayland explodes everywhere (not least QtWayland judging by the issue reports). The closest X11 gets to any kind of synchronisation is enabling vsync in the gpu driver, whereas wayland tries to do all that in software on the CPU, X11 leaves it all up to the GPU driver, and is otherwise asynchronous always - nothing "workaround" about it.

    heck, that was the whole "selling point" of wayland we've been fed for the last few years it was implicit sync "every frame is perfect" that you "couldnt do" in X11 (except you could, with vsync). Accepting that was BS is a big step for wayland, however comic the squirming is.
    Last edited by mSparks; 15 April 2024, 03:40 AM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by mSparks View Post

    X11s entire design is isolated, atomic bytestreams that are not subject to the race conditions that make wayland so unstable, that isn't implicit sync - not even close, it is however what wayland is finally trying to replicate with this new extension.
    X11 is 100% implicit sync, and always has been. It doesn't sound like you actually understand what explicit sync is about.

    Nvidia works around it by replacing a bunch of X with their own alternative code, by plugging in their x driver. xwayland didn't allow them to replace x anymore with their own private interface, which is why it didn't work for them.
    Last edited by smitty3268; 15 April 2024, 01:53 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mSparks View Post
    The proprietary NVidia driver doesn't support implicit sync at all
    There is a problem here.
    Nvidia bypasses X11 protocol as much as they can.

    Originally posted by mSparks View Post
    X11s entire design is isolated, atomic bytestreams that are not subject to the race conditions that make wayland so unstable, that isn't implicit sync - not even close, it is however what wayland is finally trying to replicate with this new extension.

    Example: Identifying a race condition in i3-wm
    Like it or not X11 protocol does race condition tools have be developed to detect it. In fact you wrote the cause of the problem. "bytestreams" being more than one. What keeps the possible multi-able X11 protocol byte-streams the application can be sending items in on synced then answer is absolutely nothing. What says that you cannot start a operation on one X11 bytestream and close it on another absolutely nothing. What says application can only have one connection open to the X11 server answer absolutely nothing. Welcome to race condition coded into the X11 protocol.

    Wayland protocol in fact does not allow this race condition. Wayland you cannot start operation on one connection and close different connection. Wayland compositor is free to restrict application to a single wayland connection and that is in the wayland protocol as well. These two changes kill the possible race condition.

    Nvidia wanted with Xwayland originally to bipass the Wayland compositor with eglstreams and it was highly unstable.

    Wayland is forcing Nvidia to use defined behavior instead of undefined behavior.

    Sometimes, black or incorrect textures appear in KDE instead of window contents or other interface elements, like widgets on the panel. One easy way to reproduce the problem is this: Toggle Kwin compositing off and then on again with a hotkey. Have multiple windows opened, from different applications. I typically use Firefox, Thunderbird, QtCreator, Kate and other KDE applications for testing. Preferably, one window should be maximized in the background. Open new windows or resize (preferably ...


    Nvidia bad behavior is not limited to Wayland. There have been on going cases with Nvidia wish to use more explicit sync than you should resulting in issues under .x.org X11 server running in bare metal.

    Nvidia forums contain issue after issue that relate to Nvidia lack of functional implicit sync on GPU memory operations. GBM/DRI3 support by Nvidia is having their driver at least add some implicit sync as in the implicit sync for memory management you need not to have disasters all the time.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by anda_skoa View Post
    So the other process' popup should appear adjecent at the main processes button?

    That is pretty easy to do with Wayland, especially in Qt.

    I have recently done that as a demo for a customer who wanted to have the UI of two existing applications integrated in such a way as to appear as one to the user.

    On X11 they try to fake this with specific rules of their window manager, but of course they are still two processes.
    So one application's modal dialog are not modal for the other.

    Yes this is like it it.
    Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...


    Will allow the old faking to work. Please note PCSX was not using window manager rules to fake it. Instead using open window at absolute position to fake it. .

    Originally posted by anda_skoa View Post
    With Wayland you can simply create a nested compositor, in my case using the Qt Wayland Compositor framework.
    You can then place the surfaces of your clients (main window, dialogs, popups) anywhere in your window as you see fit.
    None of those are even "seen" by the user session's compositor.

    Any top level window you create is associated with your main window, e.g. on top of it and so on.
    Again you can place as many of your clients surfaces into those windows.

    In my demo I even have a switch to toggle, at runtime, between showing my client's windows inline and as the host compositor's windows.
    There is extreme flexibility for this "merging of other processes' UI" that way
    PCSX2 being a game thing input latency is a thing. Having input pass though to compositors instead of one they class as a problem.
    Last edited by oiaohm; 14 April 2024, 09:59 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mSparks View Post
    So in the middle of claiming otherwise you just decide to outright state Qt is chock full of bugs,
    No you need to quote full sentences and read them.

    Originally posted by oiaohm
    Stuff like PCSX2 when it comes to GUI construction is a true abomination even under X11 it technically using what is called undefined behavior.
    This is X11 protocol undefined behavior. X11 protocol does not in fact state that all applications work from the same origin point to start off with. We have got use to that being the case because x.org X11 does but that not in fact written into the X11 protocol. This is only a start of a long list of what PCSX2 and other applications like it depend on to work that are in fact undefined behavior by the X11 protocol. Qt faking origin point on a per application under Wayland is in fact inline with X11 protocol itself.

    There is a difference between a normal bug and what Qt has done here. Qt is in reality with Wayland just emulating what X11 protocol allows. Some of the competing implementations to x.org X11 like the Haiku x11 implementation have the same behavior as Qtwayland with origin point. Majority of applications don't care if the origin point is unique to them or shared. Qtwayland and Haiku X11 both do unique to application origin point and X11 x.org server does shared origin point and both are technically right by the X11 protocol.

    Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...

    When 264 or something like it merged into Wayland protocol and solves this class of problems this will be defined behavior.

    This has been part of the process of conversion to Wayland is finding stacks of locations where applications developers have been depending on behaviors not defined in X11 protocol. Yes these undefined areas turn out that no one has really spent attempting to design those areas to be as functional as they should be as well.
    Last edited by oiaohm; 14 April 2024, 09:57 PM.

    Leave a comment:


  • mSparks
    replied
    Originally posted by Hibbelharry View Post

    Right, except that was workarounded. X11 is implicit sync.
    X11s entire design is isolated, atomic bytestreams that are not subject to the race conditions that make wayland so unstable, that isn't implicit sync - not even close, it is however what wayland is finally trying to replicate with this new extension.
    Last edited by mSparks; 14 April 2024, 08:35 PM.

    Leave a comment:

Working...
X