<jadahl>
pq: i'm sure it was, I made an attempt to understand without actually reading anything to minimize side-track time but I guess that was a bad idea
<pq>
nothing is easy in gfx :-p
<jadahl>
:P
<pq>
"Waht's a pixel?" ...
<jadahl>
"undefined"
Seirdy has quit [Ping timeout: 480 seconds]
xantoz has joined #wayland
Seirdy has joined #wayland
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #wayland
emersion has joined #wayland
juergbi has joined #wayland
<emersion>
oof, it seems daniels felt inspired and wrote another book or two on the ML regarding explicit sync
<emersion>
time to sit back and read ^^
joes has joined #wayland
<daniels>
just trying to summarise all the 5000 mails in one place
<daniels>
jekstrand did the same, but longer :P
* jadahl
appreciates not having to read 5000 e-mails
<emersion>
i'd call it a digest, not a summary ;)
<emersion>
Explicit Sync Weekly Edition, Volume 1
<pq>
to me it seems several people have moved on writing digests and summaries on the topic :-)
<pq>
*move on to
<daniels>
emersion: :D
<emersion>
but yeah, ofc, thanks for writing that up daniels :)
ecloud has joined #wayland
joes has quit [Ping timeout: 480 seconds]
GentooPhysicist has joined #wayland
haasn has joined #wayland
mort0 has joined #wayland
mort0 has left #wayland [#wayland]
mort_ has joined #wayland
ammen99[m] has quit []
ammen99[m] has joined #wayland
ammen99[m] is now known as ammen99
<zzag>
would it be sensible to allow ref'ing and unref'ing wl_shm_buffers so the compositor could upload data from a buffer to the texture even after wl_buffer.destroy?
ammen99 is now known as Guest4971
* zzag
also wonders if it's an api breaking change
<gitlab-bot>
wayland issue (Merge request) 141 in wayland "protocol: allow immediate wl_buffer.destroy if not re-used" [Protocol, Opened]
<emersion>
i had an issue about it opened for quite some time, but never got around to patch the protocol
<pq>
looks like one would need to save all the wl_shm_buffer_get_*() data at wl_shm_buffer_ref_pool() time to keep access to it.
<pq>
but keeping a pool ref also prevents resizing the pool.
<emersion>
is the mmap'ed region kept alive?
<emersion>
hm
<pq>
yes, that's the point of pool ref, to let other threads continue accessing it
<pq>
I guess you could take the pool ref on the wl_resource destroy signal
<pq>
..of the wl_buffer
<emersion>
sounds like it could work
<emersion>
not very ergonomic
<pq>
not fun indeed
<pq>
as usual with things that were original never meant to be used like this (destroy before getting release and expect the compositor to not glitch)
mcepl has joined #wayland
ebassi has joined #wayland
<pq>
zzag, is your use case that a client does an attach+damage+commit and immediately quits without waiting for anything, expecting that final frame to be actually shown?
<pq>
or would it be fine for you to re-use whatever content you already uploaded to GL?
<zzag>
pq: yep, my concern was about the case where the client attaches a new buffer and soon after that quits
<pq>
is that... realistic?
<pq>
a compositor that doesn't implement window closing animations would probably never show the last frame anyway
<pq>
if the client actually cares about the last frame being shown, it needs to subscribe to and wait for the frame callback.
<pq>
if you don't wait for the frame callback, the protocol says your frame could be overwritten by your new frame; I'd easily extend that to "never shown at all if you destroy the window"
<pq>
It's actually not about wl_buffer.release or destroy; if the client doesn't wait for frame callback, it's ok to discard the frame IMO.
<pq>
If the client does wait for frame callback, you probably already uploaded the data into GL.
<pq>
at least Weston sends frame callbacks only after upload to GL
<emersion>
aren't GL uploads synchronous anyways?
<pq>
yes?
<pq>
why?
<daniels>
emersion: hope I wasn't speaking out of turn to say that you'd implement delayed commits!
<zzag>
I'm not sure about re-using the last texture, the window can look distorted if the window geometry changes with the last commit
<zzag>
either way, it would be nice if "referenced" wl_shm_buffers don't get destroyed under the compositor's nose
<daniels>
the window geometry doesn't change unless and until the client has attached the corresponding buffer
<zzag>
correct
<pq>
Weston does not do GL upload on attach, damage, nor commit; it does it on repaint some time after commit, but before sending frame callbacks.
<daniels>
but yeah, you're racing the compositor, hoping that your content will show before the client quits ... and that the user will spot and understand the content during the single frame it's shown?
<daniels>
like, if you want something to be seen, don't immediately request that it be hidden by destroying the connection
<pq>
"KWinFT is based on wlroots"?
<pq>
I didn't think it was?
<pq>
*is
<wb9688>
pq: romangg is working on using wlroots in it
<romangg>
pq: Was this discussed earlier here in the channel or where did you read that?
<pq>
where should I have been lurking to have heard about that coming? :-D
<pq>
romangg, daniels' email on dri-devel@
<romangg>
ah, thanks
<pq>
Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6)
<romangg>
pq: regarding lurking: we talked about it in the past on #sway-devel (now on libera.chat).
<pq>
is there a kwinft dev channel?
<romangg>
For real-time I had setup a Gitter community where we discuss things: https://gitter.im/kwinft/community Can be also joined via Matrix.
<romangg>
Other than that I'm very tenacious in documenting all current developments and future plans in GitLab tickets so it's documented and can be followed by other people.
<gitlab-bot>
KWinFT issue 137 in kwinft "Render and Display backends based on wlroots" [Epic::Render, Level::Expert, Stage::Decide, Wayland, Opened]
<pq>
mm, gitlab tickets...
<romangg>
not a fan? :D
<pq>
gitlab is fine, it's the gutter/matrix I have no presence in
<romangg>
well if you have a gitlab acc you can use that to also post in gitter channels. ;) but most conceptual work is discussed anyway in the gitlab tickets.
<romangg>
(gitter is service by gitlab nowadays)
<pq>
strange, gitlab.com does not let me subscribe to that issue
<pq>
I subscribed to the "epic render" label though.
<romangg>
ok, should be also fine. it's weird that it does not let you subscribe to individual tickets though. I don't think i played around with the permissions in that regard.
<emersion>
daniels: agree to everything you said :)
<emersion>
yup, delayed commits def pretty high on the priority list
<romangg>
emersion: Looking forward to getting it "for free" soon. ;)
<romangg>
Ok, now I'm gonna sit back and will read this email chain too.
<romangg>
What's "resv"?
<romangg>
and ANI
<pq>
I'd guess "reservation", but what means exactly I'm not sure.
<pq>
AcquireNextImage, Vulkan term
gnustomp[m] has joined #wayland
<romangg>
ah right, thanks. is this explicit sync work only meant to be used via Vulkan?
<pq>
dunno
<emersion>
no, explicit sync can be used on EGL/KMS as well
<emersion>
or do you mean the new stuff?
<emersion>
for the new userspace fences stuff, everything is still in flux afaik
<romangg>
emersion: yes, these new sync files
<emersion>
sync_file means the old stuff ;)
<romangg>
lol
<emersion>
"synchronization primitive" is the generic term
<romangg>
but the patch is about "importing sync files". so isn't that the new thing?
<emersion>
ah, there are two things going on in parallel:
<emersion>
- plans for a new synchronization primitive, dubbed "userspace fence" so far. main motivation is make upcoming AMD hw work
<emersion>
- jason's patch to add a way to get a sync_file in/out of an implicitly synchronized dmabuf
<emersion>
synchronization primitives, ordered by age:
<emersion>
- sync_file (what the linux-explicit-synchronization protocol uses)
<emersion>
- (drm_)syncobj(_timeline): what vulkan uses
<emersion>
- "userspace fence": the new stuff which hasn't materialized yet
<romangg>
Thanks for the explanation emersion! Very helpful to get an overview.
<romangg>
I know we discussed that stuff already last year but I didn't remember much details anymore.
<emersion>
np :)
<emersion>
yeah this stuff is easy to forget about
<romangg>
It's good to see progress is still ongoing. When working on user space it can be difficult to keep track of lower levels or quickly get an overview again.
<pq>
"hasn't materialized yet" - what a pun :-D
<emersion>
:D
adjtm_ has quit []
adjtm has joined #wayland
<daniels>
romangg: resv is dma_resv, which lives on a dmabuf and is used as a container to hold sync_files/syncobjs for implicit sync
<daniels>
emersion: it's not just AMD hardware - Arm has much the same problem, and anyone designing natively for newer Vulkan. jekstrand being involved suggests that Intel have the exact same design coming up, and I've said it as a fact so many times without him ever denying it that it is, in fact, a fact
<emersion>
ahah, i see
blue__penquin has joined #wayland
<daniels>
he will shortly materialise and prove my point by saying that he's interested because syncobj is his baby and he's sort of the bridge between Khronos VkSemaphore work and the Linux kernel, so it's his job to make sure that we do something good and futureproof for everyone, and he's also doing i915 kernel work so it makes sense for him to do it now
<daniels>
all of which is factually correct, but again not a denial :P
* emersion
epolls on jekstrand
dblsaiko has joined #wayland
adjtm has quit []
<romangg>
I like this mildly sarcastic question form daniels mail: "maybe we should have some kind of conference where we all get together and talk to each other ... ?" :D
adjtm has joined #wayland
<romangg>
Seriously though it would be nice to have next XDC some program around it.
<romangg>
Preferably not only for the experts who know all the details already.
<daniels>
we did have one of those in Montreal, but none of us were there since it clashed against libliftoff IIRC
adjtm has quit []
adjtm has joined #wayland
<romangg>
That's a pity but probably was also pretty "experty". I'm meaning more short introduction to the topic and giving an overview. Won't maybe bring much direct value for experts like you though who want to rather agree on how to proceed than to see where we are.
<romangg>
Although it sometimes also helps the experts to remind themselves about that. ;)
blue__penquin has quit []
ebassi has quit []
ebassi has joined #wayland
ebassi has quit []
ebassi has joined #wayland
ManMower has joined #wayland
joppe has joined #wayland
joppe has quit [Remote host closed the connection]
joppe has joined #wayland
qyliss has joined #wayland
joes has quit [Ping timeout: 480 seconds]
adjtm_ has joined #wayland
adjtm has quit [Remote host closed the connection]
<pq>
one of those wtf moments... for all I understand, this code should calling into a NULL function pointer, yet I've never seen it explode.
<pq>
and then I realize, I accidentally the code
mcepl has left #wayland [#wayland]
joppe has quit [Remote host closed the connection]
joppe has joined #wayland
adjtm_ is now known as adjtm
adjtm has quit [Quit: Leaving]
adjtm has joined #wayland
<MrCooper>
pq: didn't know "accidentally" is a verb ;)
<pq>
I learnt it a long time I ago and I can't remember
<pq>
one of those meme things I guess
<MrCooper>
emersion: FWIW, I've started working on delayed commits for mutter; I have something working, it's working great on Intel (mutter runs at full frame-rate even with clients GPU-limited much lower), but I've come to realize it doesn't handle subsurfaces correcly yet, and handling all cases for those could be tricky
iinuwa[m] has left #wayland [#wayland]
<emersion>
MrCooper: you'll need to add queues to all of the surface state, not just subsurfaces
<emersion>
xdg_surface, xdg_toplevel, all of the other exts
<MrCooper>
right, that's done, the easy part :)
<emersion>
ok, nice
<pq>
that was easy part? :-O
<MrCooper>
well, maybe there's other stuff missing I just don't realize yet :)
<pq>
you're delaying all window related state, not just the buffer, right?
<jadahl>
I imagine the hard part is to splice things up in "semi global" combined states to choose from at the right time... i.e. subsurface and then eventually the transactions protocol
<emersion>
the transactions protocol is easy to implement once you have queues for all surface-related state
<jadahl>
right, it'd be identical to the subsurface handling
<MrCooper>
the thing I've realized for subsurfaces is that the queue needs to include a whole graph of committed states, which is then applied only once all the buffers in there are ready
<daniels>
there sure are some delicate interactions between those three things however
<daniels>
MrCooper: yep
<jadahl>
indeed
<MrCooper>
so that'll be a bit more complicated
<emersion>
all of the fun
<MrCooper>
but seems doable
<emersion>
maybe flattening the graph at cache-time would easy things
<jadahl>
could probably skip all these fancy things during "transitions" (window moving, animations, resizing, etc)
<emersion>
not sure it'd be spec compliant
<emersion>
ease*
<pq>
mm, yeah, if you already has state queues... Weston doesn't at all :-p
<MrCooper>
pq: yeah, mutter already had something rudimentary for subsurfaces
<jadahl>
in mutter there are state "objects", with pending/cached/...
<jadahl>
MrCooper: I change that for the transaction work a bit
<jadahl>
it's sitting in some MR
<emersion>
right. but then here you have multiple "cached" states
<daniels>
pq: well, we have the subsurface limbo queue
<daniels>
it's just ... not an especially flexible or powerful queue
<MrCooper>
jadahl: that might be useful for handling delayed commits with subsurfaces
<pq>
that's nice - weston took a shortcut and the queued state does not include any extension state, only sub-surface
<daniels>
pq: oh eek, I didn't even think of that, e.g. maximised
<pq>
yup :-D
<pq>
*all* missing, not even a mechanism to hook things
<pq>
btw. the transition from pending to next state slot is different than between any other two state slots.
<pq>
because a client can do multiple wl_surface.attach without a commit in between, and only the last attach will actually reserve the buffer.
<pq>
erm, only the last attach will remain when commit reserves the buffer
<pq>
weston has that too ad-hoc'd
<MrCooper>
mutter handles that properly AFAICT, not sure about xdg_* though
<pq>
IOW, attach A, attach B, commit; must not send wl_buffer.release for A.
<pq>
cool, cool
<jadahl>
MrCooper: xdg-shell stuff is put in that pending state too
<MrCooper>
that's a relief
<jadahl>
well, it's only window geometry
<jadahl>
the rest is pretty unrelated
<jadahl>
maximize/minimize are just loose "intents"
d10n_ is now known as d10n
<pq>
but they affect window positioning, or is window position part of your geometry?
danburd has joined #wayland
<jadahl>
they do, but that's a side effect that isn't tied to any commit
<jadahl>
or, well, it's tied to some commit via the ack
<jadahl>
but not via some request poking at a pending state
* emersion
agrees
<MrCooper>
jadahl: BTW, are you aware that weston-subsurfaces breaks with -r1 and/or -t1 parameters on mutter? Seems to work fine with both on weston
<jadahl>
MrCooper: rotates the wrong direction?
<MrCooper>
-t1 freezes when trying to resize the window
<MrCooper>
-r1 eventually aborts with "shm_surface_prepare: all buffers are held by the server."
danburd[m] has joined #wayland
<jadahl>
ah, didn't know
danburd has quit [Quit: Leaving]
<jekstrand>
emersion: -ETIME
<emersion>
eh, at last i'm not stuck in infinite-wait
adjtm is now known as Guest17
adjtm has joined #wayland
Guest17 has quit [Remote host closed the connection]
Cwiiis has joined #wayland
hir0pro has joined #wayland
hir0pro has quit [Quit: hir0pro]
hir0pro has joined #wayland
Narrat has joined #wayland
spstarr has quit [Remote host closed the connection]
<swick>
okay so what I don't get about UMF is why we care so much about the "when it's about to be done" aspect
<swick>
like, is this only about latency at that point?
<swick>
there are ways to get the "good" latency in common situations with UMF
<swick>
i.e. if the window is in a steady state and each commit only changes the buffer the compositor could do conditional rendering
<swick>
kms similarily could have at least two active slots and then scan out from the latest one which has signalled
joppe has quit []
hardening has joined #wayland
hardening has quit []
hardening has joined #wayland
neonking has joined #wayland
<pq>
jadahl, hmm, you need to carry the ack in the state then, to latch in the new window state at the same time with the new geometry and content? That is very much tied to the commit.
<jadahl>
pq: the ack is carried in the pending/cached state
<jekstrand>
emersion: Was there an actual question you wanted me to answer? Sorry, too many things flying around that I'm losing track.
<pq>
alright, so window state changes *are* queued like everything else
<jadahl>
pq: kind of, the actual *state* (maximized vs ..., global position, etc) sits somewhere else
Narrat has quit []
danshick has joined #wayland
<emersion>
jekstrand: the main question i guess was, are you participating in the discussion because intel hw will have the same issues as AMD (and Arm)?
<emersion>
so far the AMD issue appeared to be pretty AMD-specific to me, but maybe it's not
<jekstrand>
Well.....
<jadahl>
suspiciously many dots after that "Well"
<jekstrand>
We'd like to move to userspace memory fences for various reasons which sort-of have to do with new HW.
<daniels>
swick: just sent a reply in which I'm trying to point out that the exact time at when it's done (and latency/efficiency of polling for done) is totally immaterial to us, _except_ for VRR
<jekstrand>
They more have to do with the needs of industrial-strength compute workloads.
<emersion>
ok, just knowing that you want to move to user-space fences is enough to me
<jekstrand>
But we'd like it in Vulkan too because then timeline semaphores "just work"
<daniels>
jekstrand: run with the industry-standard oneAPI?
<emersion>
lol
<jekstrand>
The whole "AMD might not be able to ship new HW without fixing all of userspace" issue. Well, that's AMD's problem. They got themselves into that mess.
<jekstrand>
daniels: /* no comment */
<emersion>
^ this is a comment though
spstarr has joined #wayland
Narrat has joined #wayland
SunWuKung has joined #wayland
SunWuKung has quit [Remote host closed the connection]
<swick>
daniels: even for VRR a hotloop might not be a big problem when frames are actually scheduled for a specific time with some slack
<daniels>
agree :)
ecloud has quit [Read error: No route to host]
ecloud has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
SunWuKung has joined #wayland
ecloud has joined #wayland
kennylevinsen has joined #wayland
columbarius has joined #wayland
dos1 has joined #wayland
mstoeckl has joined #wayland
mstoeckl has left #wayland [#wayland]
mstoeckl has joined #wayland
tlwoerner has quit [Quit: Leaving]
jekstrand has quit [Read error: Connection reset by peer]