ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<bwidawsk>
I'll submit one for fractional scaling shortly too
peelz has quit [Read error: Connection reset by peer]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
glennk has joined #wayland
Leopold_ has joined #wayland
kts has joined #wayland
tzimmermann has joined #wayland
kts has quit [Quit: Leaving]
selckin has quit [Quit: selckin]
selckin has joined #wayland
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
<riteo>
folks, sorry for bringing this once more, but I'm having a real hard time figuring the proper nature of this issue
<riteo>
So, I've thought about the frame issue once more and I wonder if all we need isn't really just a "surface occluded" flag, with which to know that we can't rely on frame events anymore
<riteo>
Another reason for this though is the fact that it looks like (please correct me if I'm wrong) to "default" to vsync rate when it comes to "pacing" the WSI, if you get what I mean, which would be a bit un-ideal with "interface-y" things, like for example the godot editor
<riteo>
(I know the surface occluded flag has already been discussed but it got phased out in favor of the commit queue stuff I think, but I think that it might not fix the problem fully, although it will help a lot)
<riteo>
I'm really sorry for asking this, but if I'm saying something dumb I beg somebody to explain me the issue a bit as I'm not a graphics person at all and I think I might either be missing something or taking something impossible for granted. I really do want to allow game engines like godot engine their best possible chance at working up to their potential
<kennylevinsen>
There's the suspended flag
<riteo>
it's for "client" things though, not full rendering shenanigans I got told
<riteo>
like, "calm down animations a bit thx"
<riteo>
and it's for xdg_toplevel only, which further brings up my point
kts has joined #wayland
<riteo>
In short, my proposed approach is a bit more similar to "the old way" I suppose
<riteo>
basically, if we don't stall anymore on presenting because of the FIFO queue (that's how it works I hope), we can then fetch at whatever rate this flag and "optimize" rendering out
<riteo>
which is what godot is built to do and probably a lot of other game engines, as they're paced from the WSI and not the compositor.
<riteo>
that would still mean that compositors can't easily "throttle" them down but I'm not sure how that could be fixed honestly, outside of some "interference" WSI side, if something like this is even possible
<riteo>
I genuinely can't think of a better way out and this is confusing me down a bit tbh
<kennylevinsen>
If you didn't rely on having WSI block you could do all this already
<riteo>
The issue is that we have no reliable rate at which to fetch the frame event I suppose
<kennylevinsen>
Render at whatever rate, wait on frame event with a high timeout to unstall, go into background mode when suspend is set (likely shortly after you got frame event timeout)
<riteo>
we're basically reinventing suspension but worse
<riteo>
but maybe I'm just too dumb to understand this, maybe this is the most correct approach after all
<kennylevinsen>
You're not reinventing suspension if you *use* suspension
<riteo>
what is suspension, really, from a client's PoV?
Dami_Lu has quit [Remote host closed the connection]
<riteo>
an undefined time elapsed since the last frame event?
<kennylevinsen>
It says that the compositor is not normally rendering the surface. It's a hand-wavy way to say "stop and release your resources, you're not visible and nobody cares about you". Hand-wavy because it's not guaranteed sent in all cases where the surface is not seen
<riteo>
wait, are you referring to the xdg_toplevel event?
<kennylevinsen>
Yes
<kennylevinsen>
Hence "you can already do all this"
<kennylevinsen>
Godot can use that event itself
<riteo>
I'm pretty sure that we're still supposed to render if we get a suspended event
<riteo>
lemme give a look
<riteo>
like, it's not guaranteed that receiving it will mean that we can stop rendering
<riteo>
mh, it says that it's not ordinarily being repainted, which I'm not sure it means we can use it this way
<kennylevinsen>
reacting to frame events asynchronously would be better, but you definitely shouldn't be actively rendering in the suspended state. What can happen is that someone might want *a* new franr for a preview at some point
<kennylevinsen>
frame
<kennylevinsen>
Not sure if other compositors unset the suspended state in those cases when asking for a frame
<riteo>
wait!
<riteo>
I think you're right!
sima has joined #wayland
<riteo>
the MR body itself says: "In this state, clients can choose to take meaningful action such as suspending any processing which would drive a repaint loop"
<riteo>
So that's the intent of the protocol I suppose, which would explain the "not ordinarily repainted" thing
<riteo>
I think that this is indeed enough to fix _that_ part of the bigger problem space! I don't want to celebrate yet, but this feels like I might've misunderstood things along the way, perhaps due to the usual X-Y problem
<riteo>
If the answer to "how do I stop godot from having to guess when it can stop drawing" is this I'll be really happy
<riteo>
(before the "you just need to know when to draw", our reliance on the WSI makes it impossible AFAICT, so we have to go the other way. I still really like the frame semantics but they're not the right choice for this sadly)
<riteo>
(to be clear, not by themselves)
kts has quit [Remote host closed the connection]
kts has joined #wayland
<riteo>
kennylevinsen: thanks as usual for your help and point of view
<kennylevinsen>
You're welcome
glennk has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
glennk has joined #wayland
kts has quit []
<kennylevinsen>
One point is that there isn't a guarantee that it will come *before* frame callbacks stall. So you still need e.g. timeout on waiting for frame callbacks or something - but once you get suspended state you can cleanly move to "background" mode without guesses.
<kennylevinsen>
But try it out and see
<riteo>
we'll still probably have to "emulate vsync" (basically MAILBOX and listen to frame events) anyways so that's not a problem I suppose
<riteo>
and from what I've seen that looks "by design" when more advanced clients want to manually handle frame events
<riteo>
plus the WSI is kinda broken it looks like, judging from the commit queue stuff, so it really shouldn't be a problem. I hope I won't find some catch and have an existential crisis again lmao
<riteo>
it really wasn't a good idea to get into wayland with something such as complex and annoying as this oof
<riteo>
(not really godot as much as the whole WIP protocol shenanigans)
<riteo>
I don't think I'm terribly useful here outside of messing around with godot, hope y'all don't mind
<riteo>
(don't take this as me giving up, I still really want to help to the extent possible and I'm open to all your PoVs and information)
Dami_Lu has joined #wayland
q234rty[m][m] has quit [Quit: Client limit exceeded: 20000]
Dami_Lu has quit [Remote host closed the connection]
lsd|2 has quit [Read error: Connection reset by peer]
sevz has quit [Remote host closed the connection]
sevz has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
vaxry has quit [Remote host closed the connection]
vaxry has joined #wayland
<ids1024>
Is it ever actually valid to have a dmabuf buffer with different modifiers per plane? Given GBM doesn't even seem to have per-plane modifiers (only `gbm_bo_get_modifier`).
iomari891 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
ids1024: all planes always have the same modifier
<ids1024>
Was there some expectation that wouldn't be the case when `EGL_EXT_image_dma_buf_import_modifiers` and `linux-dmabuf-unstable-v1` were designed with a modifier specified for each plane?
<ids1024>
It might be good to document in `linux-dmabuf-unstable-v1` that the modifiers should all be the same, if that's always the case.