ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
jmdaemon has joined #wayland
Brainium has joined #wayland
columbarius has joined #wayland
mceier has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
mceier has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Arnavion has quit [Remote host closed the connection]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
Guest979 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
luna has joined #wayland
mxz has quit [Quit: cya]
sima has joined #wayland
mxz has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
luna has left #wayland [#wayland]
tzimmermann has joined #wayland
junaid has joined #wayland
dcz_ has joined #wayland
junaid has quit [Quit: leaving]
floof58 is now known as Guest988
floof58 has joined #wayland
Guest988 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
selckin has quit [Quit: selckin]
selckin has joined #wayland
rasterman has joined #wayland
kts has quit [Quit: Konversation terminated!]
mvlad has joined #wayland
kts has joined #wayland
iomari891 has joined #wayland
kts has quit [Quit: Konversation terminated!]
MajorBiscuit has joined #wayland
kts has joined #wayland
<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
<mort_>
whereby the dbus server gets notified that a client disconnects?
<emersion>
this is indeed off-topic
<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?
<qyliss>
there's a portals matrix room
<qyliss>
I think
<qyliss>
although I can't find it now, so maybe I just dreamed it…
<jadahl>
mort_: #xdg-desktop-portals:matrix.org
<mort_>
jadahl: thanks!
pochu has joined #wayland
kts has quit [Quit: Konversation terminated!]
<wb9688>
Hmm… nothing on IRC for that?
<jadahl>
sadly no, seems the world is more and more Matrix when it comes to new channels.
<emersion>
at least it's not discord lol
<wb9688>
Yeah
<wb9688>
But why do those Matrix channels not just get bridged to IRC then?
<emersion>
no idea
<emersion>
i just have a thrwoaway matrix account for this purpose
<jadahl>
wb9688: tbf, irc <-> matrix bridging works quite unreliably
<jadahl>
emersion: the only project using discord that I have contributed to is SDL and it is indeed very annoying
<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
<ramcq>
Discord can get into the sea
<ramcq>
(followed by Slack)
<MrCooper>
if I had to pick poisons, I think I'd prefer Discord over Slack :)
<ramcq>
really?! work uses Slack. Discord is _way_ worse IMO
<ramcq>
it's like designed by ADHD toddlers on drugs, I find it close to unusable
<jadahl>
MrCooper: at least slack can be used from weechat :P
<ramcq>
♥ WeeSlack
<ramcq>
weechat matrix seemed to kinda die which is a bit unfortunate
<jadahl>
yea, weeslack is my saviour
<ramcq>
or it doesn't do some keying dance properly
<ramcq>
there's no reason somebody can't make a proper console matrix client, it's just not happened yet
<ramcq>
or a UI one that doesn't make pandas very sad
<jadahl>
ramcq: sounds exactly like the XMPP situation ~20 years ago
<ramcq>
I have indeed seen this movie before, and had a very minor part in the earlier edition... 🤣
<jadahl>
same :P
<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
<jadahl>
still have 1 friend left on XMPP
<ramcq>
that's dedication
<MrCooper>
I agree ideally bridges shouldn't be necessary, then again I don't think I could tolerate Slack without the Matrix bridge
<ramcq>
I think the conceptual gap between Matrix and Slack is smaller; that's probably less jarring than trying to bridge IRC and Matrix
<jadahl>
the irc matrix bridging is more annoying because now and then messages from matrix just doesn't show up on irc at all
<jadahl>
not that they are conceptually different
<emersion>
that shouldn't happen anymore
<ramcq>
but the unreliability is a consequence of how differently they work. matrix and slack are message-based, irc is connection based
<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
<ramcq>
oh, no - it's the reverse. matrix users get kicked out if too idle, because IRC.
<ramcq>
anyway it sucks :P
fmuellner has joined #wayland
<jadahl>
emersion: happened last week
<jadahl>
(on liber chat)
<qyliss>
libera has some annoying policies for matrix
<qyliss>
the messages not showing up, and people getting kicked, are both policy decisions
<jadahl>
at the end of the day I get to see people seemingly having monologues which is entertaining in a way
<pq>
sometimes someone probably *is* having a monologue...
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
luna_ has joined #wayland
luna has joined #wayland
luna_ has quit [Remote host closed the connection]
luna has left #wayland [#wayland]
nerdopolis has joined #wayland
Company has joined #wayland
tlwoerner has joined #wayland
<Company>
So, one of the things I've been thinking about recently with GTK is moving the rendering into a thread
<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
<Company>
but I'm wondering how that code should interact with the main thread in terms of accessing Wayland resources
<emersion>
you shouldn't need to interact with wayland while rendering
<Company>
like, eglSwapBuffers() or vkQueuePresentKHR() fiddle with the wl_surface and commit() to it
nerdopolis has quit [Ping timeout: 480 seconds]
<Company>
so I'm wondering where I would best put the thread boundary between the rendering and main thread
<emersion>
you can either create a wl_proxy wrapper for that rendering thread's wl_surface
<emersion>
or signal back to the main thread that it needs to swap
<Company>
if I signal back and forth, I need multiple GL contexts I guess?
<Company>
one for swapping in the main thread and the other for rendering
<pq>
I think the main practical problem is synchronizing all other Wayland window state with the swap.
<Company>
yeah
<pq>
If you can handle that, it doesn't really matter which thread is doing the swap.
<Company>
the main thread may be handling events, resizing and whatnot
<emersion>
if you synchronize properly, i don't think you need multiple contexts
<Company>
I think a context may only be current in one thread
<pq>
Is there a cost to switching a context between two threads, though?
<emersion>
btw, what is driving this idea? have you benchmarked the rendering part and found it's slow to send GL/Vk commands?
<Company>
there's a cost to switching contexts
<Company>
the rendering part is >10% in most of the use cases where people complained about performance
<Company>
and if I can get a 10% win, that'd be neat
<Company>
plus, it seems like a good testing ground for multithreading the GTK backend, because it's very self-contained
<Company>
pq: I got some gains from never clearing the context
<pq>
so people want the main thread to be free to do more work while waiting for rendering to finish?
<Company>
pq: early GTK used to MakeCurrent(NULL) when it was finished with a frame, and removing that sped things up
<Company>
pq: people want to run application code
<Company>
and application code is mostly event handling - once things are set up, they can go do their thing on their own
<pq>
ok
<Company>
which in GTK's case would be 4 big things: CSS validation, layout, snapshot (generating the draw instructions) and rendering
<Company>
layout and snapshot call into widget vfuncs, so they may run user code, which makes them hard to move to threads
<pq>
what do you do when app code posts more rendering than the rendering frame can handle?
<pq>
*thread
<Company>
but rendering is just the act of translating the draw instructions into Vulkan/GL commands
<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
<MrCooper>
and you could do optimizations such as attaching an app buffer to the surface directly
<Company>
pq: we have various processes in place that check things - we have the same problem in a single thread after all
<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)
<Company>
MrCooper: right, that'd be the other approach, telling the thread to give us a wl_buffer when it's done
<pq>
I meant more like app code running 13 frames ahead of rendering.
Moprius has joined #wayland
<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...
<Company>
MrCooper: that doesn't work too well with egl and Vulkan's infra though
<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
<Company>
kennylevinsen: and then the backend can do whatever in response to that
<Company>
kinda like how the web does things, too - the JS application code that interacts with the DOM all runs in the main thread
<MrCooper>
Company: out of curiosity, what are the issues with EGL/Vulkan infra?
<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
<Company>
MrCooper: and I know they attach() and commit() to the wl_surface, so they're not threadsafe
<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.
<Company>
MrCooper: I'm not much further than that atm
<pq>
or GBM alloc + EGL Surfaceless
<Company>
yeah, that seems painful
<pq>
it is, somewhat
<kennylevinsen>
a little bit, but then you get all the control with no API emulation
<kennylevinsen>
eglSwapBuffers and eglSwapInterval, I'm looking at you
<Company>
different question: frame callbacks
<pq>
why don't we have a lib doing all the GBM and zwp_linux_dmabuf handling...
<Company>
when do I request the frame callback? Can I do that without attaching a new buffer?
rasterman has quit [Read error: No route to host]
<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
<pq>
why would you need it if you're not posting a buffer?
<Company>
ie the case where rendering and main thread 80% of the CPU time each
<Company>
if we wait for both to finish, that's 1.6 frames, otherwise we post every frame, just a frame late
<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
<Company>
buffer + damage + opaque region + ...
<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
<Company>
yeah, it's more involved in detail
<Company>
I was mostly wondering what to best hang the frame events off of
<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
<Company>
and the 2nd quarter, everything below gsk_renderer_render() essentially, would go off into a thread
<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.
<Company>
that's roughly 20% in that case
<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.
<pq>
maybe you can postpone the snapshot step until frame callback comes back? Just spin everything else in the mean time.
<MrCooper>
to get the same behaviour as on X, it would need to have two frames in flight
<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?
<pq>
what makes it faster on x11?
<pq>
oh, GTK's own scheduling
<MrCooper>
pretty much, no multiple threads required though, just concurrency between CPU & GPU
<pq>
is that concurrency lost because Mutter waits for the wl_buffer to become ready until signalling frame callback for the commit?
<MrCooper>
partially, yeah
<pq>
gotcha
<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?
<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).
<pq>
main thread could even re-draw without the swap message if it needs to (e.g. resize pending?)
<MrCooper>
Company: ^ sounds like something to think about / play with :)
<DodoGTA>
What could cause XWayland Vulkan to have 0.5 ms frametime spikes with high GPU load? 🤔️
<pq>
the Wayland compositor's own rendering, perhaps?
<DodoGTA>
I'll have to try the KDE X11 session to confirm it's a Wayland/XWayland issue
Moprius has quit [Ping timeout: 480 seconds]
<pq>
is that GPU time or CPU time? realtime or active time or task time?
hugosvirak has joined #wayland
melonai has joined #wayland
rv1sr has joined #wayland
<DodoGTA>
pq: MangoHUD doesn't tell that information, but it might be GPU time
<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?
<Company>
MrCooper: especially in the threaded context when the main thread is 2 frames off?
<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...
<kennylevinsen>
frame callbacks will fire as always, often when the pageflip succeeds (or on some timer from page flip for frame scheduling)
hugosvirak has quit [Remote host closed the connection]
<Company>
the thing we want to achieve is smooth animations
<Company>
like, think about some slider that moves 10px/s
<Company>
we want to know how far along we should draw it for the next frame
<kennylevinsen>
Yeah but with VRR, the timing is driven by the compositor which in turn is driven by client commit timings (or other magic)
<MrCooper>
Company: the best you can do for that might be extrapolating into the future based on presentation-time feedback
<Company>
right
<Company>
I think it's gonna be good enough to not be noticeable
<emersion>
wlroots sends the lower bound on predicted next refresh rate with presentation-time
<emersion>
with that, if the client renders in time, the new content will show up at that predicted timestamp