02:19 wlb: weston Issue #755 opened by bot crack (unintialized) [weston 11.0.1] QT button is not released https://gitlab.freedesktop.org/wayland/weston/-/issues/755
09:01 mort_: Sorry if this is the wrong channel, but: in the portal dbus APIs, there's a concept of a "session". A bunch of compositor-side resources are presumably associated with the session. The client can call Close on the session to close it, but what if it doesn't, what if the dbus client crashes or something before it calls Close? Is there a mechanism
09:01 mort_: whereby the dbus server gets notified that a client disconnects?
09:02 emersion: this is indeed off-topic
09:03 mort_: figured it might be on topic since the portal API is so integral to wayland, but fair enough. Do you happen to know of a channel where it might be more on-topic?
09:04 qyliss: there's a portals matrix room
09:04 qyliss: I think
09:05 qyliss: although I can't find it now, so maybe I just dreamed it…
09:34 jadahl: mort_: #xdg-desktop-portals:matrix.org
09:34 mort_: jadahl: thanks!
10:12 wb9688: Hmm… nothing on IRC for that?
10:35 jadahl: sadly no, seems the world is more and more Matrix when it comes to new channels.
10:36 emersion: at least it's not discord lol
10:39 wb9688: Yeah
10:40 wb9688: But why do those Matrix channels not just get bridged to IRC then?
10:40 emersion: no idea
10:40 emersion: i just have a thrwoaway matrix account for this purpose
10:41 jadahl: wb9688: tbf, irc <-> matrix bridging works quite unreliably
10:42 jadahl: emersion: the only project using discord that I have contributed to is SDL and it is indeed very annoying
10:42 ramcq: yeah I don't love or hate Matrix, it's "meh", but if you're going to do it, its better not to use the bridging because that's explicitly worse for both IRC and Matrix users
10:43 ramcq: Discord can get into the sea
10:43 ramcq: (followed by Slack)
10:43 MrCooper: if I had to pick poisons, I think I'd prefer Discord over Slack :)
10:43 ramcq: really?! work uses Slack. Discord is _way_ worse IMO
10:43 ramcq: it's like designed by ADHD toddlers on drugs, I find it close to unusable
10:44 jadahl: MrCooper: at least slack can be used from weechat :P
10:44 ramcq: ♥ WeeSlack
10:44 ramcq: weechat matrix seemed to kinda die which is a bit unfortunate
10:44 jadahl: yea, weeslack is my saviour
10:44 ramcq: or it doesn't do some keying dance properly
10:44 emersion: you could try https://github.com/progval/matrix2051/
10:44 ramcq: there's no reason somebody can't make a proper console matrix client, it's just not happened yet
10:45 ramcq: or a UI one that doesn't make pandas very sad
10:45 jadahl: ramcq: sounds exactly like the XMPP situation ~20 years ago
10:45 ramcq: I have indeed seen this movie before, and had a very minor part in the earlier edition... 🤣
10:46 jadahl: same :P
10:46 ramcq: which is why I continue to maintain, based on bitter personal experience, that abstractions and gateways are a terrible idea and you should just write/use a client that's capable of speaking the protocol you want to use
10:46 jadahl: still have 1 friend left on XMPP
10:46 ramcq: that's dedication
10:48 MrCooper: I agree ideally bridges shouldn't be necessary, then again I don't think I could tolerate Slack without the Matrix bridge
10:50 ramcq: I think the conceptual gap between Matrix and Slack is smaller; that's probably less jarring than trying to bridge IRC and Matrix
10:51 jadahl: the irc matrix bridging is more annoying because now and then messages from matrix just doesn't show up on irc at all
10:52 jadahl: not that they are conceptually different
10:53 emersion: that shouldn't happen anymore
10:58 ramcq: but the unreliability is a consequence of how differently they work. matrix and slack are message-based, irc is connection based
10:58 ramcq: Fedora has this really bad because they (or Librera.Chat) matrix bridges kick IRC users out for being idle, to lower load on the gateways
10:59 ramcq: oh, no - it's the reverse. matrix users get kicked out if too idle, because IRC.
10:59 ramcq: anyway it sucks :P
11:26 jadahl: emersion: happened last week
11:26 jadahl: (on liber chat)
11:28 qyliss: libera has some annoying policies for matrix
11:28 qyliss: the messages not showing up, and people getting kicked, are both policy decisions
11:29 jadahl: at the end of the day I get to see people seemingly having monologues which is entertaining in a way
11:34 pq: sometimes someone probably *is* having a monologue...
11:42 emersion: can i get on ACK on this? https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/315
13:07 Company: So, one of the things I've been thinking about recently with GTK is moving the rendering into a thread
13:08 Company: it is pretty self-contained (because we record our drawing instructions and then the renderer replays them), so that could be quite a big gain
13:08 Company: but I'm wondering how that code should interact with the main thread in terms of accessing Wayland resources
13:08 emersion: you shouldn't need to interact with wayland while rendering
13:09 Company: like, eglSwapBuffers() or vkQueuePresentKHR() fiddle with the wl_surface and commit() to it
13:09 Company: so I'm wondering where I would best put the thread boundary between the rendering and main thread
13:10 emersion: you can either create a wl_proxy wrapper for that rendering thread's wl_surface
13:10 emersion: or signal back to the main thread that it needs to swap
13:10 Company: if I signal back and forth, I need multiple GL contexts I guess?
13:11 Company: one for swapping in the main thread and the other for rendering
13:11 pq: I think the main practical problem is synchronizing all other Wayland window state with the swap.
13:12 Company: yeah
13:12 pq: If you can handle that, it doesn't really matter which thread is doing the swap.
13:12 Company: the main thread may be handling events, resizing and whatnot
13:13 emersion: if you synchronize properly, i don't think you need multiple contexts
13:13 Company: I think a context may only be current in one thread
13:13 pq: Is there a cost to switching a context between two threads, though?
13:13 emersion: btw, what is driving this idea? have you benchmarked the rendering part and found it's slow to send GL/Vk commands?
13:14 Company: there's a cost to switching contexts
13:14 Company: the rendering part is >10% in most of the use cases where people complained about performance
13:14 Company: and if I can get a 10% win, that'd be neat
13:15 Company: plus, it seems like a good testing ground for multithreading the GTK backend, because it's very self-contained
13:16 Company: pq: I got some gains from never clearing the context
13:16 pq: so people want the main thread to be free to do more work while waiting for rendering to finish?
13:16 Company: pq: early GTK used to MakeCurrent(NULL) when it was finished with a frame, and removing that sped things up
13:17 Company: pq: people want to run application code
13:18 Company: and application code is mostly event handling - once things are set up, they can go do their thing on their own
13:18 pq: ok
13:18 Company: which in GTK's case would be 4 big things: CSS validation, layout, snapshot (generating the draw instructions) and rendering
13:19 Company: layout and snapshot call into widget vfuncs, so they may run user code, which makes them hard to move to threads
13:19 pq: what do you do when app code posts more rendering than the rendering frame can handle?
13:19 pq: *thread
13:19 Company: but rendering is just the act of translating the draw instructions into Vulkan/GL commands
13:20 MrCooper: Company: as discussed before on #gnome-shell, a possible alternative might be not using an EGL surface, then the main thread can commit to the surface without having to worry about GL contexts
13:20 MrCooper: and you could do optimizations such as attaching an app buffer to the surface directly
13:20 Company: pq: we have various processes in place that check things - we have the same problem in a single thread after all
13:21 Company: pq: when we emit more GPU commands than the GPU can handle (usually that's been us overloading the PCIe bus with memory transfers)
13:22 Company: MrCooper: right, that'd be the other approach, telling the thread to give us a wl_buffer when it's done
13:22 pq: I meant more like app code running 13 frames ahead of rendering.
13:22 kennylevinsen: random thought: what about kicking the application code to their own thread and leaving main for everything Gtk? If things need to be made thread safe anyway...
13:22 Company: MrCooper: that doesn't work too well with egl and Vulkan's infra though
13:23 Company: kennylevinsen: my main goal is to keep the GTK API in a single thread (which I call the main thread), so apps don't care about threadig
13:23 Company: kennylevinsen: and then the backend can do whatever in response to that
13:24 Company: kinda like how the web does things, too - the JS application code that interacts with the DOM all runs in the main thread
13:24 MrCooper: Company: out of curiosity, what are the issues with EGL/Vulkan infra?
13:25 Company: MrCooper: no idea what they would be in detail, but I know EGL and VkSwapChain do a bunch of work that I'd need to learn about and duplicate
13:26 Company: MrCooper: and I know they attach() and commit() to the wl_surface, so they're not threadsafe
13:26 pq: You'd stop using EGL Wayland platform completely if you go the wl_buffer way. It'd be EGL GBM (or maybe EGL Device?) platform.
13:26 Company: MrCooper: I'm not much further than that atm
13:27 pq: or GBM alloc + EGL Surfaceless
13:27 Company: yeah, that seems painful
13:27 pq: it is, somewhat
13:27 kennylevinsen: a little bit, but then you get all the control with no API emulation
13:28 kennylevinsen: eglSwapBuffers and eglSwapInterval, I'm looking at you
13:29 Company: different question: frame callbacks
13:29 pq: why don't we have a lib doing all the GBM and zwp_linux_dmabuf handling...
13:29 Company: when do I request the frame callback? Can I do that without attaching a new buffer?
13:30 Company: because the main thread doesn't really care about what the render thread is doing and wants to start preparing the next frame, even if the render thread isn't done yet
13:30 pq: why would you need it if you're not posting a buffer?
13:30 Company: ie the case where rendering and main thread 80% of the CPU time each
13:31 Company: if we wait for both to finish, that's 1.6 frames, otherwise we post every frame, just a frame late
13:33 Company: so I'd basically need to do 2 commits per frame: Once when the main thread is done with all its stuff (and requesting a frame callback), and once when the rendering is done with all the rendering stuff
13:33 Company: buffer + damage + opaque region + ...
13:34 MrCooper: sounds like you're really asking about frame scheduling in GTK, which I don't think is just a matter of when to request frame events; the crux is that the client may need to start working on the next frame before the frame event for the previous frame arrives
13:35 Company: yeah, it's more involved in detail
13:35 Company: I was mostly wondering what to best hang the frame events off of
13:36 MrCooper: when requesting a frame event without attaching a buffer in the same commit, it's not clearly defined when the frame event will be sent
13:37 Company: that does limit the choices quite a bit
13:46 Company: emersion: a random testcase that gives a neat overview of where time is spent is scrolling a huge list like https://gitlab.gnome.org/GNOME/gtk/uploads/fa51696a9ef46c44f3309c8289fb1142/Screenshot_from_2022-06-07_08-45-08.png
13:46 Company: emersion: which gives this flamegraph: https://gitlab.gnome.org/GNOME/gtk/uploads/314000dc5bb0860bb2775ff2d2e3f5f8/image.png
13:46 Company: and the 2nd quarter, everything below gsk_renderer_render() essentially, would go off into a thread
13:47 pq: right, if your rendering thread is committing the buffers, then the main thread asynchronously asking for frame callbacks would be totally bogus, even if the frame callback behavior in that was well-defined.
13:47 Company: that's roughly 20% in that case
13:49 pq: my first suggestion would be for the thread that commits buffers and all other window state to also ask for the frame callback, and then have the main thread not start a new rendering job until the frame callback has passed.
13:49 wlb: wayland-protocols Merge request !202 merged \o/ (stable/xdg-shell: clarify when which protocol errors are used https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/202)
13:49 wlb: wayland-protocols/main: Xaver Hugl * stable/xdg-shell: clarify when which protocol errors are used https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/bbe9298e8522 stable/xdg-shell/xdg-shell.xml
13:51 Company: making the rendering thread do the throttling and hanging the main thread off of that - yeah, could work
13:52 Company: worst case would be doing 1 frame of unnecessary work
13:52 MrCooper: pq: note that GTK currently waits for the frame event before drawing the next frame, and it results in issues such as https://gitlab.gnome.org/GNOME/gtk/-/issues/5773
13:53 pq: maybe you can postpone the snapshot step until frame callback comes back? Just spin everything else in the mean time.
13:54 MrCooper: to get the same behaviour as on X, it would need to have two frames in flight
13:55 pq: do you mean that preparing and rendering one frame takes longer than one refresh cycle, but splitting those into multiple threads and pipelining you can reach full throughput with longer latency?
13:59 pq: what makes it faster on x11?
14:00 pq: oh, GTK's own scheduling
14:00 MrCooper: pretty much, no multiple threads required though, just concurrency between CPU & GPU
14:01 pq: is that concurrency lost because Mutter waits for the wl_buffer to become ready until signalling frame callback for the commit?
14:02 MrCooper: partially, yeah
14:02 pq: gotcha
14:03 pq: Maybe in that case, the rendering thread would be trottled by frame callback itself, and the main thread re-draw would be trottled by the rendering thread saying it has swapped?
14:06 pq: main thread can do a re-draw and kick it to the rendering thread, but the rendering thread will wait for the previous frame callback before rendering. In the mean time, the main thread could kick another draw, which then replaced the waiting draw (and accumulated Wayland window state).
14:07 pq: main thread could even re-draw without the swap message if it needs to (e.g. resize pending?)
14:09 MrCooper: Company: ^ sounds like something to think about / play with :)
14:14 DodoGTA: What could cause XWayland Vulkan to have 0.5 ms frametime spikes with high GPU load? 🤔️
14:16 pq: the Wayland compositor's own rendering, perhaps?
14:18 DodoGTA: I'll have to try the KDE X11 session to confirm it's a Wayland/XWayland issue
14:31 pq: is that GPU time or CPU time? realtime or active time or task time?
15:06 DodoGTA: pq: MangoHUD doesn't tell that information, but it might be GPU time
15:06 Company: MrCooper: random other thought: How does VRR play into frame callbacks and making GTK predict the right timestamp to prepare the next frame for?
15:07 Company: MrCooper: especially in the threaded context when the main thread is 2 frames off?
15:10 kennylevinsen: there is no right timestamp for the next frame under VRR, there is at most a range of possible frame times. Without more VRR work to e.g. dictate which applications get to "drive" VRR, such timing is not that useful...
15:11 kennylevinsen: frame callbacks will fire as always, often when the pageflip succeeds (or on some timer from page flip for frame scheduling)
15:19 Company: the thing we want to achieve is smooth animations
15:20 Company: like, think about some slider that moves 10px/s
15:20 Company: we want to know how far along we should draw it for the next frame
15:26 kennylevinsen: Yeah but with VRR, the timing is driven by the compositor which in turn is driven by client commit timings (or other magic)
15:29 MrCooper: Company: the best you can do for that might be extrapolating into the future based on presentation-time feedback
15:30 Company: right
15:30 Company: I think it's gonna be good enough to not be noticeable
15:30 emersion: wlroots sends the lower bound on predicted next refresh rate with presentation-time
15:31 emersion: with that, if the client renders in time, the new content will show up at that predicted timestamp
15:41 MrCooper: emersion: https://wayland.app/protocols/presentation-time#wp_presentation_feedback:event:presented says: "If the output does not have a constant refresh rate, explicit video mode switches excluded, then the refresh argument must be zero"
15:42 emersion: this is about headless and such
15:43 MrCooper: seems to pretty clearly apply to VRR
15:44 MrCooper: what you describe is somewhat misleading for a client which runs at frame rate around the minimum refresh rate
15:45 emersion: if VRR was off, it'd be misleading as well
15:45 emersion: a slow client cannot use the predicted refresh rate in a meaningful way
15:52 MrCooper: I see your point, might be good to clarify this in the spec though
18:12 wlb: wayland Merge request !318 opened by Simon Ser (emersion) server: use bool in struct fields https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/318 [IPC library]
18:59 heeen[m]: Would Wayland benefit from io_uring in any way?
19:01 Ermine: heeen[m]: if compositor uses it, then maybe
19:22 kennylevinsen: heeen[m]: in any noticable way that would make it worthwhile? no. would it be slightly cool? yes.
19:29 wb9688: "slightly cool" lol
23:24 wlb: weston Merge request !1245 opened by Leandro Ribeiro (leandrohrb) color-lcms: print curve sets on pipeline optimizer debug scope https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1245