Announcement

Collapse
No announcement yet.

KWin-LowLatency: An Effort To Yield Less Stutter & Lower Latency With The KDE Desktop

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

  • shmerl
    replied
    Originally posted by tildearrow View Post

    Adding a Vulkan back-end to the compositor will be an extremely tough task as I have zero knowledge of Vulkan.

    I will eventually have a look at Wayland, however.
    It's probably a good investment of time though to learn it for this use case. Looks like wlroots developers are working through this, but the main issue is not simply Vulkan familiarity (it's pretty new for everyone), but lot's of parts that need to be put together to make it work.

    The way I see it, there are good reasons for developers to focus on Vulkan/WSI instead of legacy OpenGL/EGL. Bringing Vulkan support up on new hardware (or rather hardware yet without drivers) is a lot easier than bringing up the whole legacy OpenGL (or GLES) stack there. Imagine this happening for example for Vivante GPU (like for Librem 5). If KWin and other compositors could use Vulkan, it could take less time to develop full open solution than if GLES was required and developers had to chisel all the GL support first.

    So I don't buy the argument of some KWin developers, that using Vulkan is pointless.
    Last edited by shmerl; 05-08-2019, 03:37 PM.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by oiaohm View Post

    Really stop being clueless. IBM and Amazon don't work in the GUI field of KDE at all. Your nobody claim was bogus here counted straight by the next post.



    The question about "Vulkan" is interesting. Vulkan in the windows manager allows better cpu and gpu usage over opengl path. So you want to reduce added latency by compositor Vulkan is a good path. That is even if the compositor is running on X11.

    Lets follow this question forwards what do you really need with X11.

    Yes you need X but do you in fact need GLX. That interesting point xwayland uses a EGL(OpenGL ES) and forwards GLX to that and allows applications using EGL to bypass.

    1) EGL(OpenGL ES) can be used under X11 and Wayland.
    2) GLX is only under X11.
    3) No EGL support under X11 equals what.

    The reality here is no EGL support under X11 equals a stack of not working programs.

    Any sane developer looking at a X11 compositor patch that requires GLX and does not support EGL(OpenGL ES) applications would be saying that need to develop more before merging because who wants broken applications.

    Really this is not example of developer stupidity rejecting a patch. This is just another example of your stupidity debianxfce not understanding the interrelationships and requirements.

    Solutions under X11 for compositor need to support GLX and EGL applications running on X11. Wayland gets simpler even with xwayland your compositor only has to deal with EGL because all GLX is converted to EGL.

    GLX in the X11 server is one of areas that there is an internal API cluster of disaster behind it that need to go away to fix a stack of performance problems.

    https://www.phoronix.com/scan.php?pa...-Beta-3-Vulkan
    I forgot to include this. Long term GLX will be redirected to EGL or Vulkan and EGL will be redirected to Vulkan.

    So X11 running on top of Wayland long term everything could be just front end for Vulkan. Short term we are needing EGL support with wayland and xwayland glx is already redirected to EGL.
    Let me clarify. When I said "EGL isn't supported" I did not mean "EGL applications aren't supported". What I meant is that KWin-lowlatency will only work using the GLX backend (which is what almost everyone uses when using KWin on X11 since the EGL on X backend is deprecated even by KDE developers themselves).
    The reason why I have not supported EGL yet (especially for Wayland) is because I haven't found any EGL extension that would allow me to explicitly wait until next VBlank (to be able to later sleep and thus reduce latency). Yes, I do need such extension, as Mesa's bugged VSync behavior requires me to. The closest I've found was the vendor-specific extension EGL_CHROMIUM_sync_control, but unless you're OK with the compositor busy-waiting (nobody is), then it is pretty much useless.
    The other method is to bring the old DRM VBlank waiting code to Wayland, but then it won't work on NVIDIA......
    Last edited by tildearrow; 05-08-2019, 03:16 PM.

    Leave a comment:


  • shmerl
    replied
    Originally posted by Awesomeness View Post

    Wrong. The majority uses Mesa drivers and KWin on Wayland works just fine with them. There are a few regressions but far from "completely broken".
    Those aren't regressions, but missing features. I.e. it's not working properly. You can say it works partially, but it means it's not ready.

    Leave a comment:


  • aufkrawall
    replied
    Originally posted by Awesomeness View Post
    Yeah, give X11 another 30 years. X11 surely gets finished and fixed by then.
    It's a common misunderstanding that X11 would be generally broken in terms of performance or vsync, but it's not true.
    Without atomic modesetting kernel driver (which also affects Wayland...), performance is completely fine with Mesa/xf86-DDX. New experimental xrender backend in Compton works perfectly for me.
    Gnome Shell/Mutter is btw. also very good since 3.32.

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by aufkrawall View Post
    Too bad KWin on Xorg was declared legacy before it was neither finished nor fixed. Poor management of priorities of what's important.
    Yeah, give X11 another 30 years. X11 surely gets finished and fixed by then.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by R41N3R View Post
    I agree with the comments of several others, ideally we need to get a low latency Kwin based on Wayland and Vulkan.
    Adding a Vulkan back-end to the compositor will be an extremely tough task as I have zero knowledge of Vulkan.

    I will eventually have a look at Wayland, however.

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by fuzz View Post
    KWin on wayland is completely broken for the majority of users, as far as I can tell.
    Wrong. The majority uses Mesa drivers and KWin on Wayland works just fine with them. There are a few regressions but far from "completely broken".

    Leave a comment:


  • DoMiNeLa10
    replied
    Originally posted by schmidtbag View Post
    What exactly is resulting in the stuttering? My crappy i3 Haswell laptop with integrated graphics works very smoothly with kwin+Wayland, even with the compositing effects and high CPU load. Although I don't think a Vulkan compositor needs to be a high priority, I do think it's a better idea than whatever else they intend to do to improve latency.


    Speak for yourself. Even though my gaming PC uses X11, I deliberately keep vsync on because I prefer a tear-free experience over input latency. Sure, a hard cap of 60Hz is dumb (assuming your display goes higher) and I agree there should be a [user-friendly] way to disable vsync, but you are heavily exaggerating your preferences as though they're what everyone else prefers.
    For me, it's even easier. I don't need to enable vsync everywhere, if there's some software where I prefer no tearing, I just set VBLANK_MODE to the desired value when I'm starting it. In practice, that means only the web browser, as smooth scrolling looks bad with (low refresh rate) tearing. At higher refresh rates vsync becomes irrelevant, because of how hard it is to notice torn frames.

    Leave a comment:


  • Ironmask
    replied
    Originally posted by czz0 View Post
    Wayland will always be useless for gaming so long as they keep forcing Vsync, with no way to disable it.

    The fact that Wayland and Gnome developers thought it would be okay to force Vsync and even hard cap the refresh rate to 60Hz (only recently fixed in Gnome), makes me have almost zero trust in them for gaming performance.
    But Windows (the compositor, DWM.EXE) forces Vsync on all windows. It seems to work fine there.

    I agree being able to disable it would be nice, but I don't think it's as big of a detriment as you think.

    Leave a comment:


  • fuzz
    replied
    Originally posted by oiaohm View Post

    https://www.youtube.com/watch?v=FYItn1jvkbI

    Really not as broken as you would first presume. KWin on wayland has some very interesting new testing features. Like this one where you can test for multi display output with a single display.
    It's 100% unusable for me. The bugs have been documented as far as I can tell. Theoretical use cases don't mean something works well. Not blaming anyone, it's just how software development goes.

    Leave a comment:

Working...
X