ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<riteo>
oh boy it's been a while and I only now notice that pq answered me, I'm very sorry
<riteo>
let's see
<riteo>
pq, so, re: the messages you said me (again, sorry a lot for the delay), your suggestions are really interesting and clear up most of the ideas behind wayland
<riteo>
so, thanks!
nerdopolis has quit [Ping timeout: 480 seconds]
<riteo>
The messy thing is as usual the rendering though. I do agree that it's not a black or white situation. re: the timer, wouldn't one be inaccurate from the screen or somehow "shift out of phase"?
<riteo>
Also, since godot is used for many things, including UI tools (like the editor itself), I think that we'd like indeed to get rendering dictated by the frame event.
<riteo>
re: risky design, it indeed is unfortunately. Godot's rendering architecture wasn't really thought with Wayland's way of doing things sadly but I hope to have mitigated as much risky behaviour as possible with compromises such as the one described above your answer
<riteo>
still, I don't think that it's _that_ different scheduling a draw. There are some edge cases due to lazy rendering but they should be "contained" pretty reasonably rn, due to various things.
<riteo>
The real problem is _when_ to read that scheduled draw. Since we're don't have the whole graphics stack timing us anymore, we have to tick at a fixed frequency, and I found that ticking at something like 144 Hz gave some really wonky frame times
mxz- has quit [Quit: cya]
<riteo>
I bumped the tick rate to something like 2000 Hz and that improved things but that's obviously not ideal. I'm not even sure if that's possible to resolve, as we _must_ poll the draw schedule somehow and somewhen.
mxz has joined #wayland
<riteo>
although, the wonky frame time might come from how we "schedule" frames, as we receive messages from the Wayland thread, do physics/input/whatever logic, draw and the cycle restarts. We might be "missing" very often frame schedules because we're not checking at the right time
<riteo>
still, to get back to discussion, that's the intrinsic issue I wanted to point out: we want to use frame events manually, so we have to somehow poll at an _undetermined_ frequency for schedules since our rendering code is main-loop dependent
<riteo>
I wonder if this is a real issue or if I'm misguided
qaqland has quit [Quit: The router is out of power]
slim has quit [Quit: slim]
qaqland has joined #wayland
kts has joined #wayland
junaid has joined #wayland
Moprius has joined #wayland
junaid has quit [Remote host closed the connection]
Moprius has quit [Quit: bye]
kts has quit [Quit: Leaving]
fmuellner has joined #wayland
andreasbackx has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
sima has joined #wayland
nerdopolis has joined #wayland
Company has joined #wayland
kts has joined #wayland
Brainium has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<DemiMarie>
riteo: I think the problem is that you have other code depending on your rendering.
<DemiMarie>
The Wayland-native solution is to decouple rendering from all other operations. Networking, physics, and other events do not cause a synchronous redraw, and instead merely update a data structure in memory. Your rendering code then uses that data structure to draw frames at the rate the system requires them, which might even be zero.
psykose has joined #wayland
<DemiMarie>
By separating rendering from other operations, you avoid drawing frames that will be discarded, saving CPU and GPU time and power consumption.
<any1>
I am running into a cleanup problem when the compositor goes away from under a client. The compositor often cleans up all proxies within destroy_queued_closure() which is called from wl_display_dispatch_queue_pending().
<any1>
I was under the impression that the client was responsible for cleaning up all resources, but this causes double free.
<any1>
Is this how it's supposed to be?
<emersion>
where is the UAF? client or compositor?
junaid has joined #wayland
<any1>
UAF?
<psykose>
use after free
<any1>
client
<any1>
This is probably a rather poorly tested use-case. I added a "detached mode" to wayvnc, so that it can re-attach if the compositor goes away.
<any1>
I clean up all resources when the compositor goes away and the re-attach when it comes back up.
nerdopolis has joined #wayland
<Arnavion>
I heard Qt6 does that too, so you could check if their code has any caveats
<riteo>
DemiMarie: indeed. It's hard to do though, especially with an unmerged branch. I'll definitely put this issue to the rendering team somehow
<riteo>
My biggest concern is, though: rendering is just showing stuff, but that stuff has to be updated every so often
<riteo>
in a video game stuff is updated at the same pace of drawing (the `_process` method in godot parlance), but with this essential mechanism broken how often are we supposed to update the state that we're rendering now?
overholts has quit [Quit: overholts]
overholts has joined #wayland
<any1>
Turns out I was dealing with improper cleanup in my own project...
<DemiMarie>
riteo: Do you have one or more separate rendering thread, or do you draw on the same thread that handles other events? If you have one or more separate rendering threads, I suspect you will already have the needed synchronization. Otherwise, event-driven rendering would mean that rendering happens in a separate callback from other event handling.
<DemiMarie>
So instead of a single method that does physics, drawing, etc, there would be separate callbacks for each event that comes in.
bri has joined #wayland
bri is now known as Guest9879
<Guest9879>
Hi? Does anybody know if wayland supports telling applications to render at a decimal scaling factor (example 1.75), instead of doing the integer scaling thing of x ?
rasterman has quit [Quit: Gettin' stinky!]
<kennylevinsen>
Guest9879: yes, with the fractional scale protocol.
<Guest9879>
Thanks!
<riteo>
DemiMarie: I'm not really that experienced with the rendering architecture of godot
<DemiMarie>
I suspect the answer to “how often” is “however often your game requires”, which might or might not be the same as the frame rate.
<riteo>
Apparently we have an option for a rendering thread, but it actually just runs a new thread every invocation so that the process loop can work in the meantime
<riteo>
also, we have a separate Wayland thread altogether since we want to be able to handle events while the game is crunching data
<riteo>
otherwise we fill the whole wayland event loop and it crashes beatifully
<riteo>
s/loop/queue
<kennylevinsen>
So your issue is that your main thread was previously throttled by some vsync equivalent, and only handled events in batches before rendering?
<riteo>
pretty much
<riteo>
we have another ticking mechanism, but that's for suspended windows (e.g. minimized)
<riteo>
and it's pretty low and fixed, which is not ideal for our use case
<kennylevinsen>
If you have a Wayland thread, you could have it signal a condition on frame event. The main thread could then wait on that with a timeout (the timeout in case the window is hidden)
<riteo>
that could be done, but what would the timeout be?
<riteo>
I think that the current approach is pretty similar to that
<kennylevinsen>
Something equivalent to the background ticking mechanism, as it indicates a hidden window
<riteo>
basically we force the "suspended" tick rate to 2000 Hz or something and check every main loop iteration with a flag if we can draw, otherwise we just `_process` stuff
<kennylevinsen>
2000 Hz o.O
<riteo>
yeah otherwise frame times would go all wonky
<riteo>
they still are, it's just less wonky this way
<riteo>
this is obviously wrong but it's the best thing I could figure out
<riteo>
probably having rendering completely separate would be a lot better
<riteo>
but still, finding a reasonable amount of time to tick will be hard, especially without breaking a lot of API or conventions
<kennylevinsen>
I was thinking more like 10. An average monitor would give you a tick of 60Hz, no reason to suddenly go 40 times faster than that when no one is looking at the output
<riteo>
it's going always like that xD
<riteo>
right now we tick a lot and if in the meanwhile the event polling logic got a frame request we draw in that single iteration
<riteo>
I've heard about the timeout heuristic but it looks pretty finnicky to me
<riteo>
like, this compromise is obviously wrong but it also makes a lot of sense, especially if we eventually get completely independent drawing
<kennylevinsen>
I understand game-esque logic where your process all pending events, then render, then block until vsync or similar - but busy-looping at 2000Hz sounds like a broken attempt at emulating a proper event loop :S
<riteo>
it is lol
<riteo>
that's just the best I could do without touching the actual main loop logic
Guest9879 has quit [Quit: Page closed]
<riteo>
godot is still multiplatform after all
<riteo>
after it gets merged we can hopefully find a better solution that might be a bit more invasive
<kennylevinsen>
Either way if your loop is used to blocking until vsync when a frame is drawn, you might be fine with 60Hz rather than 2000Hz
<kennylevinsen>
Maybe you can't go to 10 like I wanted, but if it can handle 60 sometimes it might be less wasteful to just do that all the time
<riteo>
Frame times got really wonky in my experience and what about 144 hz displays?
<riteo>
or 240?
<kennylevinsen>
If the timer timing out, frames are not visible
<kennylevinsen>
The moment the window is visible you'd get 240Hz or whatever
<riteo>
In my uneducated mind I wonder if we couldn't like write all of the drawing commands in something akin to a double-buffered queue and sync only that swap, so that when we want we can draw without waiting for a full physics update and do it all from the wl thred
<riteo>
kennylevinsen: what timer? That's the biggest issue with this approach
<kennylevinsen>
Any in that state is solely to make the window not super out of date when it is shown again later (e.g. what blocked it was removed)
<kennylevinsen>
Timeout on waiting on the condition
<riteo>
yeah, how much though
<riteo>
wait too little and it triggers that condition every time (e.g. throttled from the compositor), wait too much and it's annoying
<riteo>
and then there's the stalled situation where the game is crunching hard, a few seconds pass and then because of the execution order it could be thinking that it's suspended while it's actually not
<kennylevinsen>
As mentioned, as slow as does not break Godot - but at least like a slow monitor as Godot should be able to handle that. Inconsistent frame timing are fine for frames never shown - only the last frame before the window is revealed again might end up briefly seen.
<riteo>
mh, maybe we could use this heuristic just for rendering
<kennylevinsen>
(You would of course also use the suspended state to stop rendering when it's clearly not needed)
<riteo>
I'm still very concerned about the "as slow as does not break godot" for some reason
<riteo>
like, that value is pretty much "infinitely slow"
<kennylevinsen>
Well, then I see no reason for concern - go slow. Breaking in this case would be that expected background behavior stops working
<kennylevinsen>
Like audio playback glitching
<riteo>
busy looping, while a bit inefficient, is completely robust
<kennylevinsen>
If there are no such concerns, from my perspective you could stop ticking altogether
<kennylevinsen>
Why waste cycles on nothing of interest?
<riteo>
kennylevinsen: unfortunately `_process` is also used for networking
<riteo>
and an awful lot of other vital things, hence the alternative "suspended" ticking logic
<kennylevinsen>
But either way, if Godot is normally throttled to 60Hz, there should never be a reason to waste cycles going *faster* than that. 144Hz monitors do not matter when it's not on screen.
<riteo>
so, to recap
<riteo>
I'd wait for the frame event right before drawing?
<riteo>
and timeout
<riteo>
no wait, before processing anything else
<riteo>
mh, I think I actually tried this approach just yesterday and I didn't feel a difference. Maybe it's because of some other variable, but if that would improve cpu utilization...
<riteo>
I'll experiment a bit with your approach and see what happens, thanks
<kennylevinsen>
Using frame events keep you in sync with the monitor, not polling at a gajillion hertz saves you cpu
<DemiMarie>
riteo: so `_process` being used for networking needs to be fixed anyway
<riteo>
mh I think there's a problem though
<riteo>
we'd still have to manually poll the event thread
<DemiMarie>
why?
<riteo>
unless I use some threading primitive I suppose
<DemiMarie>
why not have a single event loop that includes everything?
<riteo>
but rn we just have `DisplayServer::process_events`
<kennylevinsen>
DemiMarie: well yeah, this thing needs a proper event loop, it's more about how to salvage it for now
<riteo>
and we'd have to call it while `!DisplayServer::get_singleton()->can_any_window_draw()`
<riteo>
so we'd still be burning the CPU
<riteo>
unless we throttle _that_ too, but then we're at square one
<LaserEyess>
well, if that's not the proper approach then what is? it basically lets you skip all of the guesswork of "when am I going to need to render next?"
<LaserEyess>
maybe there's a newer version of that particular protocol, the idea gets discussed and debated *constantly*
<kennylevinsen>
proper event loop: sleeping in the kernel until events occur, being waken up at exactly the right time with zero wasted CPU cycles - rather than busy-looping
<DemiMarie>
LaserEyess: The protocol would help but it would not solve Godot’s design problem
<LaserEyess>
I guess this is what I get for not fully reading the backlog
<riteo>
DemiMarie: mh, maybe
<DemiMarie>
In Godot, this would mean that networking/storage/rendering/etc are all based on callbacks
<riteo>
I'd have to discuss this with the various teams
<riteo>
the annoying part is compatibility
<kennylevinsen>
riteo: I think I might need a recap of hoe Godot does this on other platforms and why this doesn't work on Wayland before I'd be able to help more.
<DemiMarie>
riteo: compatibility with other platforms or with existing code?
<kennylevinsen>
well event loops with compatibility with everything already exist
<riteo>
existing games
<DemiMarie>
I see
<riteo>
I think that there is already _some_ infrastructure for that, the main loop is actually pretty opaque under that aspect
<riteo>
like, games already receive notifications, which are then wrapped into cutesy little methods for the most common ones AFAIK
<DemiMarie>
At the C++ level this means callbacks or C++20 coroutines
<riteo>
we have our own homebrew stuff
<riteo>
we have callables, fancy function pointers
<riteo>
I think that's what you're talking about?
<DemiMarie>
sort of
<DemiMarie>
With an event-driven main loop things can happen in any order
<riteo>
anyways, to give a very rough idea of how this stuff works
<riteo>
We have `OS` classes, one for LinuxBSD, one for Windows and so on
abeltramo589523 has quit [Read error: Connection reset by peer]
<riteo>
They implement `main`, like the actual entrypoint. Then, at least the LinuxBSD one processes events, joypad input and then calls the actual main loop logic, implemented in, well `MainLoop`
<riteo>
The process stuff is implemented into `DisplayServer`s, of which there can be multiple per platform to support multiple backends like X11 and Wayland in the same binary
<riteo>
so, DS -> joypad -> main and so on
<riteo>
the main loop then processes, renders, updates physics, VR and anything else (not in this order)
<LaserEyess>
do you have a link to the API?
<riteo>
during process we actually check if we can draw and either normally draw (and let the graphics stack wait for us) or we go into "low consumption" mode, where we basically loop at 144 hz (by default) without drawing (but still calling `_process`)
<riteo>
LaserEyess: the docs are available over at docs.godotengine.org
<DemiMarie>
_process is the problem here
<riteo>
most of this stuff I'm saying comes from playing around a lot with those specific areas of code
abeltramo589523 has joined #wayland
<riteo>
DemiMarie: yeah I think it's mostly that. All notifications are "manually" sent though
<DemiMarie>
With an event-driven main loop, the main loop handles not just input events, but also timers, network activity, and all other I/O
<riteo>
so there's also the issue at the root where we must still poll for when to update physics, and send various events such as input stuff
<DemiMarie>
Physics would be “whenever the game needs”
<riteo>
at least physics have a static tick rate
<riteo>
it has it's own notification, `_physics_process`
<DemiMarie>
Every main loop I know of has its own timer handling code
<riteo>
ours too
<LaserEyess>
riteo: it looks like the main loop is separate from your OS/DS classes, and also that games can provide their own
<DemiMarie>
But that timer handling is implemented via callback-on-completion at the API level
<riteo>
we actually just manually wait
<riteo>
like with sleep
<DemiMarie>
that’s an antipattern
<riteo>
either nothing IIRC or the low consumption mode tickrate
<DemiMarie>
The proper solution is to use epoll (Linux)/kqueue (BSD)/etc to wait until an event happens
<DemiMarie>
You then use an API to get a notification from the OS when something has happened
<riteo>
we also sync with the renderer though if that helps
<DemiMarie>
“Something” = I/O has completed, timer has expired, etc
<DemiMarie>
And pretty much your whole program runs in various event handlers
<riteo>
would all of those polls be into different threads?
<DemiMarie>
no
<kennylevinsen>
polling interfaces allow you to wait for any number of event sources all at once
<riteo>
oh all right
<DemiMarie>
exactly
<DemiMarie>
you can wait for tens of thousands of events at once without any performance problems
<riteo>
so we just poll for a lot of stuff at once and if any changes we check, update, rinse and repeat
<riteo>
that's definitely a pretty radical change
<kennylevinsen>
yup - you get informed of exactly which events have occurred (e.g., traffic on wayland socket, so you need to dispatch wayland, traffic on joystick event device so you need to read that, ...)
<DemiMarie>
yup
<kennylevinsen>
and event loops also allow timer, signal and idle events so you can do whatever "soft" events you want, or batch everything up to simulate existing behavior
<riteo>
not sure if that's doable in the current release cycle, but I think that it shouldn't be too hard to implement while keeping compatibility
<kennylevinsen>
yeah it would be a pretty big surgery, which is why I was suggesting more of a hack :P
<kennylevinsen>
definitely not a last-minute merge
<riteo>
yeah we're definitely in hack-land here
<riteo>
I'm pretty sure that the current approach and your proposed one are actually pretty similar
<kennylevinsen>
that might be - what do you do right now?
<riteo>
like, if we add a timeout we're actually enforcing a minimum amount of iterations
<LaserEyess>
honestly I'm pretty shocked to hear that godot is busywaiting instead of using a real event loop
<LaserEyess>
even on windows?
<kennylevinsen>
the timeout is mainly to avoid the unexpected stall as a window gets hidden just as you render
<riteo>
LaserEyess: boy, is it that weird? I might be missing something perhaps
<riteo>
I'm not _that_ experienced with Godot's core logic
<DemiMarie>
On Windows you will need a separate thread to handle I/O completion ports and post a message to the message loop
<kennylevinsen>
if you use the suspended state so you know when windows are e.g. minimized, you shouldn't hit the timeout too often on supported compositor - so it's just anti-stall
<riteo>
kennylevinsen: we're ticking at a defined rate and draw if between iterations we get a frame event
<kennylevinsen>
and with that in mind I think it's fine to make it slow
<DemiMarie>
Or the reverse: pump window messages on a separate thread and use PostQueuedCompletionStatus()
<riteo>
by adding a time out we're still enforcing a minimum tickrate I think
<riteo>
so we're doing pretty much the same thing I think
<DemiMarie>
riteo: It’s not really *weird*, more somewhat naive
<kennylevinsen>
yeah, that seems fine
<kennylevinsen>
well I don't like the ticks at all, but again the solution to that is an event loop
<DemiMarie>
Don’t try to rush event loop support in, though
<riteo>
kennylevinsen: I do agree that it's weird to tick at 2000 Hz though, but that makes it bullet-proof on a lot of setups
<riteo>
DemiMarie: AFAIK the main core logic hasn't changed ever, but again, there might be some more cleverness higher in the stack
<kennylevinsen>
the main option you have here is to slow down your tick rate to the monitor refresh if that's something that aligns with godot
<LaserEyess>
riteo: I am not a gamedev and I have no idea how major game engines work but I would imagine that you're hitting the CPU too hard and adding too much latency for e.g. games that need 200+ Hz
<riteo>
like, we got multithreaded scene tree updating and stuff liek that
<LaserEyess>
and yes I concur with switching to an event loop being a massive change likely worthy of a major version bump
<DemiMarie>
riteo: It’s going to be a big change indeed
<riteo>
LaserEyess: ironically it lowers the frametime from what I've experienced
<DemiMarie>
riteo: Higher frame rate is not always good
<LaserEyess>
well if you poll at 2000 Hz then I mean yeah you can brute force it
<riteo>
because we're not updating physics every 2000ths of a second, but still at the fixed rate
<LaserEyess>
oh
<riteo>
DemiMarie: I'm not talking about higher frame rate, but less noisy frame times
<DemiMarie>
riteo: I see
<riteo>
it sohuldn't be too hard to like poll the event loop at a different rate than the rest of the stuff though if that's annoying
andreasbackx has quit [Remote host closed the connection]
<kennylevinsen>
I definitely wouldn't want an application I use to poll at 2000Hz, but if I'm playing a game I probably won't care too much as long as it works
<riteo>
but that's the problem, we still have to poll the event thread somehow from the main thread, so there's always a tickrate
andreasbackx has joined #wayland
<DemiMarie>
nope
<DemiMarie>
not with a fully event driven design
<riteo>
yeah, I know that
<DemiMarie>
but for now, yeah
<riteo>
but from the main thread-oriented design that's how it works
<riteo>
in a way, that looks by design
<kennylevinsen>
riteo: if you wanted to be "smart", you could average the frame times and use that after a while
<riteo>
that could be done
<riteo>
we already have some delta smoothing after all
<LaserEyess>
well you can use multiple threads with an event loop, and even an event loop per thread, but in addition to not being a gamedev I am also not an expert on multithreaded and/or lockless programming so I would probably not do that