Announcement

Collapse
No announcement yet.

Vulkan Wayland Compositors Are Nearing Reality

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

  • dragon321
    replied
    With dma-buf support in Nvidia drivers maybe this will finally solve this Nvidia vs Everyone mess.

    Leave a comment:


  • reba
    replied
    On top: Vulkan has a CPU-only implementation "Lavapipe" (Phoronix article).

    While this might create an additional overhead it should make even the weirdest platform (with or without a GPU at all) Vulkan-compatible and thus - makes every Vulkan-based application (e.g. here: compositors) available to the user.

    Even the ones who bought into nvidia will have this absolute fallback available to them, no matter what.

    Disclaimer: that is, if I understood their project correctly


    Edit:
    Holy Moly, it actually works - spinning cubes!
    Code:
    [FONT=monospace][COLOR=#000000]$ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json vkcube [/COLOR]
    WARNING: lavapipe is not a conformant vulkan implementation, testing use only.[/FONT]
    Oh yeah, and Quake of course: https://www.youtube.com/watch?v=Goed4wr2jf4
    Last edited by reba; 21 January 2021, 03:34 PM.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by bofh80
    while, that's nice. n all. great work. kudos all around.
    however, would someone put me out of my misery and tell me WHY we need 3d for desktop?
    What's wrong with the fastest path, cpu? like we've been doing for years. (with or without buggy 2d accel).
    And i don't mean the software emulated compositor. . Unless you're going to tell me it's as fast and responsive as.
    Is it just the resolutions we use these days or what?
    (I don't care for stupid fancy effects, i'm looking for some technical reasons beyond eye candy)

    Considering that most of you are using a composited desktop i expect a lot of considered responses.
    Actually the main benefits have little to do with being 3D and more
    • Vuilkan was designed with multi threading/parallelism in mind which means it will make it easier to do smoother/responsive compositing by delegating work on multiple threads
    • Vulkan is a lot lower level than OpenGL which ultimately gives more control to programmers allowing them to squeeze more performance
    My response is assuming we are making a comparison to OpenGL on a GPU, if we are dealing with CPU compositing than Vulkan will be much much faster and responsive

    Leave a comment:


  • iskra32
    replied
    Originally posted by bofh80

    That's interesting. I would be interested in the 'tricks to reduce input latency'. Any pointers?

    Thanks for the reply!
    I am not certain how other compositors do it, but Kwin(once 5.21 releases of course) for example estimates how long compositing will take based on past frames, and then does it just in time before a vblank. This means that hypothetically there shouldn't be *any* latency beyond the usual(and unavoidable due to how displays work) delay between frames.

    Leave a comment:


  • mihau
    replied
    Originally posted by bofh80

    That's interesting. I would be interested in the 'tricks to reduce input latency'. Any pointers?

    Thanks for the reply!
    I'm not the person you're replying to, but for one you can use repaint scheduling to delay compositing until just before vblank, so that the image is as up to date as possible while still vsynced. wlroots and weston already do this (with a static delay) and mutter is also working on it. You can also use hardware planes to effectively offload compositing to hardware, avoiding copying and compositing latency. A good example of this is the cursor plane - notice how the cursor never suffers from compositing latency.

    Here's a good article on the topic: https://raphlinus.github.io/ui/graph...r-is-evil.html

    Leave a comment:


  • Sonadow
    replied
    Compositor maintainers can add all the stuff they want as long as the OpenGL option remains maintained.

    As a Nouveau user, it's the only thing I can use.

    Leave a comment:


  • Alexmitter
    replied
    GBM is a buffer manager, EGLStreams is a generic API to manage buffers but way too limited for Wayland.
    EGL is a API for applications to create a default context for graphics APIs on a display server.
    Vulkan or OpenGL/GLES here are mainly in the context of the compositor doing compositing work.

    GBM will still be needed in the future and Nvidia will in short or longer terms have to adopt it, it is the better solution.

    Leave a comment:


  • kenjitamura
    replied
    Originally posted by polarathene View Post

    Even if you're not fond of any eye-candy, depending on DE it would make sense to prefer the more performant choice for such when it comes to supporting those who would like such.

    What's your definition of eye candy though?
    Some day there will be a fiery Michael Bay movie explosion following behind my cursor as it moves across the screen that grows in intensity the further the mouse moves from its initial position. Just wait.

    Leave a comment:


  • loganj
    replied
    i wonder if vulkan DEs will draw more power from the GPU or will be the same or less of GL.

    Leave a comment:


  • shmerl
    replied
    Originally posted by CommunityMember View Post

    It would appear that you may have forgotten the article from around 50 days ago about nVidia implementing DMA_BUF: https://www.phoronix.com/scan.php?pa...UF-Wayland-KDE although the details were a bit sparse.
    I don't think it will fully fix their problem. Those kernel issues weren't resolved because they are about GPL. Unless Nvidia will come up with some even more weird dance around it, but then kernel developers will shoot it down even more strongly than before.

    Leave a comment:

Working...
X