Announcement

Collapse
No announcement yet.

XWayland 22.1.1 Released - Fixes Some Windowed Apps Stuck To 58 FPS

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

  • #11
    Originally posted by mdedetrich View Post

    I just read this issue and the last comment by James Jones at https://gitlab.freedesktop.org/xorg/...7#note_1275874 indicates in some ways how backwards the Linux GPU stack is. It appears that a lot of Linux GPU developers still have their heads (and in effect implementations of software) stuck in an outdated 90's views of how graphics cards/drivers work.
    You noticed his rant is directed towards Xorg and the old and outdated assumptions being baked into it? And that a proper fix would once again be to change X.org fundamentally? Thats just one more reason why X11 has to go.

    Comment


    • #12
      Originally posted by remenic View Post
      Yes I've seen that mentioned by James Jones from NVidia, but why isn't Xorg affected by this lack of implicit synchronization?
      Presumably their Xorg driver handles implicit synchronization. With Wayland, the kernel driver would need to handle it instead.

      Originally posted by tildearrow View Post
      This is why milliseconds should not be used anymore (not for video rates and not for audio buffer sizes as well). It's too imprecise for the exact value of 16 2/3ms.
      The article was slightly misleading there. The issue wasn't an incorrect calculation, it was the fallback timer getting hit at all. The fix makes the MSC tick in sync with the Wayland compositor's redraw cycle, as intended.

      Originally posted by mdedetrich View Post

      I just read this issue and the last comment by James Jones at https://gitlab.freedesktop.org/xorg/...7#note_1275874 indicates in some ways how backwards the Linux GPU stack is. It appears that a lot of Linux GPU developers still have their heads (and in effect implementations of software) stuck in an outdated 90's views of how graphics cards/drivers work.
      Implicit synchronization is how the Linux graphics stack has been working for two decades. In all that time, none of the proponents of explicit sync have stepped up to make at least a working prototype to demonstrate the claimed benefits. I for one am not holding my breath.

      Comment


      • #13
        Originally posted by MrCooper View Post

        Implicit synchronization is how the Linux graphics stack has been working for two decades. In all that time, none of the proponents of explicit sync have stepped up to make at least a working prototype to demonstrate the claimed benefits. I for one am not holding my breath.
        Yes and thats why its outdated and incompatble with how modern GPU's work. This isn't an issue with NVidia, open source drivers have similar problems with API's like Vulkan which are deliberately designed to give lower level access to the GPU. You can get away with implicit synchronization for high level API's like OpenGL but then you quickly start having issues when you go lower level.

        The matter of fact is that just as stated in that thread, implicit synchronization is no longer the correct model for modern GPU's. If you want really good performance then representing everything as simplistic read/write buffers that don't have real explicit synchronization is just going to cause problems.

        This btw was one major reason why, even with all of its faults, NVidia tried to push EGLStreams, its because the EGLStreams has an expicit asynchronous API which didn't have any performance penalty.

        So yeah you can have the conclusion that "implicit synchronization" is the way that Linux works, in which case Linux is outdated by 2 decades because the other main OS that treats their graphics stack seriously (Windows) doesn't have this model either, and for good reason.

        Comment


        • #14
          Originally posted by mdedetrich View Post

          Yes and thats why its outdated and incompatble with how modern GPU's work. This isn't an issue with NVidia,
          Yes, the issue which started this sub-thread only happens with the nvidia driver (and maybe some proprietary drivers for embedded GPUs). Upstream drivers have to support implicit synchronization (and can optionally support explicit synchronization as well).

          open source drivers have similar problems with API's like Vulkan which are deliberately designed to give lower level access to the GPU. You can get away with implicit synchronization for high level API's like OpenGL but then you quickly start having issues when you go lower level.

          The matter of fact is that just as stated in that thread, implicit synchronization is no longer the correct model for modern GPU's. If you want really good performance then representing everything as simplistic read/write buffers that don't have real explicit synchronization is just going to cause problems.
          If that's the case, I'd have expected someone to have made an explicit synchronization prototype which demonstrates it by now.

          Colour me skeptical, though. radeonsi/RADV using implicit synchronization are competitive with nvidia's drivers using explicit synchronization. I don't think James means to suggest that with explicit synchronization, the former would wipe the floor with the latter.

          BTW, as hinted above, implicit vs explicit synchronization isn't a binary choice. Jason Ekstrand posted a patch series which showed converting between the two as needed is possible.

          Comment


          • #15
            Originally posted by MrCooper View Post

            Yes, the issue which started this sub-thread only happens with the nvidia driver (and maybe some proprietary drivers for embedded GPUs). Upstream drivers have to support implicit synchronization (and can optionally support explicit synchronization as well).
            Right and the point is that the default should be explicit synchronization, not implicit. If Linux is enforcing implicit synchronization, its enforcing a technically inferior solution.


            Originally posted by MrCooper View Post
            If that's the case, I'd have expected someone to have made an explicit synchronization prototype which demonstrates it by now.

            Colour me skeptical, though. radeonsi/RADV using implicit synchronization are competitive with nvidia's drivers using explicit synchronization. I don't think James means to suggest that with explicit synchronization, the former would wipe the floor with the latter.

            BTW, as hinted above, implicit vs explicit synchronization isn't a binary choice. Jason Ekstrand posted a patch series which showed converting between the two as needed is possible.
            It isn't as simple as you put it, implicit synchronization works okay if you have a reduced problem space/and or higher level API's. For example since most games still run in DirectX <= 11/OpenGL you won't find too much of a difference between between implicit and explicit synchronization because since the API's are so high level and a lot of state is deliberately (by design) hidden this synchronization is handled by the driver.

            The problem occurs with newer API's (i.e., like Vulkan) and with newer protocol's like Wayland (Wayland is still technically implicit synchronization in design but after realizing how stupid this decision is there is some movement to change it). In these cases explicit is strictly better if you want better performance. https://lwn.net/Articles/814587/ is an extremely good article on the matter. In fact technically speaking in general explicit is far superior to implicit, its just that the performance difference is larger with the mentioned use cases, especially when you get to massively concurrent/multithreaded problems explicit synchronization along with explicit state is the only way to have sane performance (and I actually deal with this all the time in a different context, i.e. parallel backend services).

            The point here is that NVidia's driver is actually too correct, in the sense that because they care about performance so much that they don't even bother with implementing implicit synchronization when its not needed and they don't want to because its in reality the worst option.

            I am sorry to burst your bubble here, but the issue here specifically is that Linux is relying on technical inferior/outdated designs. As noted in the previous article, the Linux ecosystem is well aware of this and this is exactly what James point is, there is no reason for Nvidia to spend time and effort implementing an inferior design (implicit synchronization) for the XWayland compositor. The best solution is for X to support explicit synchronization (which they should have at some point but for reason's he stated they kind of did not). Wayland being designed with implicit synchronization was also stupid but thats a discussion for another day.

            As a last point, NVidia has been complaining about this exact same problem for almost a decade now, in fact their main reason for not even taking Wayland seriously is because Wayland didn't solve what NVidia sees as a one of the biggest problems with Linux and its graphics stack, i.e. implicit synchronization. This is the main reason why NVidia went to all of the trouble to create EGLStreams. Unfortunately a lot of cases of "shoot the messenger" because "NVidia is evil" meant that their complaints were largely completely ignored. The larger problem is that because Linux's desktop market share is so miniscule, no one even really cares about performance there which along withe unnecessary "everything must be a simple read/write buffer as a file" mantra (which works until it doesn't, and in this case it doesn't) didn't help.
            Last edited by mdedetrich; 05 April 2022, 06:53 PM.

            Comment

            Working...
            X