01:00 airlied: agd5f: yes whatever misc/xe/i915 do
05:27 airlied: robclark: did I not get an msm pull for next?
10:16 Venemo: airlied: what do you mean by "moving to dim"? what is dim?
10:20 daniels: agd5f: we already have https://gitlab.freedesktop.org/drm/amd/ so presumably we'd need to move that to drm/amd/issues or so and create drm/amd/kernel
10:20 daniels: Venemo: https://drm.pages.freedesktop.org/maintainer-tools/
13:21 robclark: airlied: hmm, I sent something on the first but now I can find no trace of the email... let me resend
13:24 robclark: airlied: resent
13:50 alyssa: HdkR: CN tower is a bit far from the venue
13:51 alyssa: Chelsea Hotel on gerard is usually a safe bet
13:53 alyssa: I see lots of choices online near the venue but yeah
14:38 karolherbst: oh right.. I still have to book the hotel as well..
15:10 Hazematman: karolherbst: better do it fast, hotel prices in Toronto around XDC are crazy atm
15:12 tjaalton: karolherbst: hum, rusticl now ftbfs on big-endian archs
15:13 tjaalton: related https://catfox.life/2024/11/29/the-complexities-of-enabling-opencl-support/
15:13 tjaalton: though I wonder why it didn't fail before 26.2
15:17 tjaalton: I don't have mesa-libclc yet, though it probably wouldn't make a difference?
15:17 tjaalton: full log on s390x https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=s390x&ver=26.2.1-1&stamp=1787230952&raw=0
16:19 HdkR: alyssa: Oh sorry, I didn't mean around CN tower. Just was thinking ones heading in that direction. Since I'll want to walk to Bruger Priest at least once as well :P
16:19 HdkR: Burger Priest
16:26 HdkR: The Chelsea hotel seems reasonable enough although.
17:19 paulgdpr: Hi! I'm recently fixed IMMEDIATE mode on wayland (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43744) and now I would like to fix FIFO_RELAXED which also doesn't work (neither wayland, nor xwayland) and so I'm going into a rabbit hole and there's many things I don't understand.
17:19 paulgdpr: One question I have is how are wayland's WSI supposed to get double buffering? It seems impossible because of https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_common_wayland.c#L1821
18:11 zamundaaa[m]: Why would you want "double buffering"?
18:22 alyssa: tearing
18:24 MrCooper: orthogonal
18:25 paulgdpr: I don't really need it, I'm just trying to understand things :) but in a scenario where 60FPS FRR is easy to reach, that's what I would want in order the have low and stable latency
18:25 MrCooper: that's really up to the app
18:27 paulgdpr: @MrCooper: I thought so but it doesn't work wayland's WSI doesn't allow setting 2 as the minImageCount
18:28 MrCooper: that should be fixed then
18:29 paulgdpr: This line agrees: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_common_wayland.c#L1846
18:29 paulgdpr: it seems that it was meant to only set 3 as a default but actually the code enforces it as a strict minimum
18:31 paulgdpr: I guess i'll try to submit a MR then
18:31 MrCooper: re FIFO_RELAXED, those semantics aren't directly supported yet on Wayland; the native WSI can probably get close using the commit-timing & tearing protocols, with Xwayland I doubt it can work as intended without changes in Xwayland though
18:32 paulgdpr: I have a WIP implementation kinda working already
18:34 paulgdpr: presentation_feedback has everything needed
18:34 paulgdpr: and tearing_hints ofc
18:34 MrCooper: without commit-timing, you can get tearing even if the presentation isn't late
18:35 MrCooper: because the compositor doesn't know the target
18:39 paulgdpr: I don't think commit-timing can help because it tells "don't present this frame before that time " but I would ideally need "don't present that vsynced frame after that vblank." and even better "or else, tear it"
18:39 MrCooper: my idea is to set the timing constraint in the target vertical blank period, so the compositor can present it without tearing if it's not late
18:40 paulgdpr: X11 protocol was much better in this respect as far as I understand, you could simply say "present this frame at this MSC"
18:41 MrCooper: per above, the current Present extension implementation in Xwayland won't result in FIFO_RELAXED semantics though
18:45 MrCooper: it sounds like your native implementation also decides whether or not to use tearing on the client side, in which case it's the same issue
18:45 paulgdpr: MrCooper: hum, I don't understand your proposition. Do you suggest sending all frame with the teraing hint attached, and a commit-time that targets the next vblank?
18:45 MrCooper: yep
18:46 paulgdpr: hum, that feels smart but weird too :)
18:47 MrCooper: if the client decides whether or not to allow tearing, there will be no tearing in some cases where there should be per FIFO_RELAXED, because the client expects the presentation to hit the target, but it actually doesn't
18:47 paulgdpr: sending all frames with the tearing hint but trying to make them land at the vblanc
18:47 zamundaaa[m]: That wouldn't be fifo_relaxed, that would just be weird tearing
18:47 zamundaaa[m]: It's highly unlikely the compositor would be able to target presentation that precisely
18:48 MrCooper: it's the closest I can see getting without a specific Wayland protocol
18:49 paulgdpr: I completly agree that it feels like it's impossible to do cleanly without a new protocol
18:49 zamundaaa[m]: I agree, but it's not quite what the Vulkan presentation mode would need
18:50 paulgdpr: my current implementation uses presentation_feedback to compute when the next vblanc should happen, and then decide to send the tearing hint or not
18:50 paulgdpr: but it's fragile too
18:51 paulgdpr: but also, I think the wayland WSI sometimes lies about when the next vblank will happen and I think it might be the reason of the weird frame pacing i sometime have
18:51 MrCooper: not sure "can't believe it's not FIFO_RELAXED" really makes sense though
18:53 paulgdpr: MrCooper: I'm sorry i don't follow, where does this quote comes from: "can't believe it's not FIFO_RELAXED"
18:55 MrCooper: it's a reference to "Can't believe it's not butter", a product which is marketed as being almost indistinguishable from butter, but isn't butter
18:55 paulgdpr: Oh ok, I'm not a native speaker :)
18:56 MrCooper: similarly your implementation advertises FIFO_RELAXED but doesn't actually provide its semantics
18:57 paulgdpr: why?
18:58 paulgdpr: my understanding is that it's quite simple: if frame is on time for vblank, send vsynced; otherwise if late, send teared
18:59 MrCooper: per above, the client can't know whether or not the presentation will make the target, so it can't reliably decide whether or not tearing should be allowed
18:59 paulgdpr: ah yes yes 100%
18:59 karolherbst: tjaalton: uhh.. I guess that's big endian related...
19:00 paulgdpr: MrCooper: so do you think a MR with such a fragile implementation is worthwhile, or would it be rejected?
19:00 tjaalton: karolherbst: yup, disabled rusticl on those, at least for now
19:00 karolherbst: yeah.. I'm sure rusticl is broken on BE...
19:00 paulgdpr: right now FIFO_RELAXED silently falls back to FIFO
19:01 karolherbst: maybe we just want to error or something... that's all very non trivial because of GPU interactions and such
19:03 karolherbst: tjaalton: but.. at least libclc is now only required by rusticl, so vulkan/gl won't require it even for drivers that use OpenCL C
19:04 zamundaaa[m]: paulgdpr: it shouldn't be supported, not fall back to anything
19:04 zamundaaa[m]: If you're looking into implementing it, do you know of any apps actually using it btw?
19:05 paulgdpr: zamundaaa[m]: I think it's not even a explicit fallback in the code, it just a broken implementation that behaves like FIFO
19:06 MrCooper: personally I wouldn't bother with anything which can't actually ensure the proper semantics, it's not up to me though
19:06 paulgdpr: zamundaaa[m]: It's quite a common presentation mode that's often called "Adaptive Sync" in games or in windows drivers
19:07 paulgdpr: For instance I think all Doom games have it
19:08 paulgdpr: and even if the game doesn't offer it, I would be happy with MESA_VK_WSI_PRESENT_MODE=relaxed
19:09 paulgdpr: I think it sometimes called Smart Sync also. It's not Fast Sync however
19:12 zamundaaa[m]: paulgdpr: adaptive sync is something very different
19:12 zamundaaa[m]: Wouldn't be surprised if some games get these things confused though
19:13 paulgdpr: MrCooper: even if the semantics ain't perfectly followed, it can still be beneficial. In my WIP code, I substract a safety margin of 500us before the expected time of the next vblank. That way, I ensure the frame is never both late and vsynced, which would cause a massive jitter. And worse case scenario, it'll tear a frame that shouldn't just before the vblanc
19:13 paulgdpr: which would result in a tear near the bottom of the screen
19:16 paulgdpr: zamundaaa[m]: ah, that's what I thought too.. Do you have sources I can read about it?
19:16 MrCooper: sounds like you're emulating commit-timing on the client side as well :(
19:17 MrCooper: a client currently can't know the compositor's deadline for hitting a given refresh cycle without tearing, so "a safety margin of 500us" isn't reliably possible
19:17 paulgdpr: I know 100% sure RBDOOM3-BFG has "Adaptive Sync" and it uses FIFO_RELAXED on vulkan. But it might be the only exception, then
19:18 paulgdpr: MrCooper: yeah but at least my vsynced frame are really vsynced ;)
19:18 MrCooper: I guess "Adaptive Sync" might be yet another overloaded term (it's the VESA term for VRR)
19:19 MrCooper: paulgdpr: some frames will have tearing when they shouldn't or vice versa, no way around it
19:20 paulgdpr: yes, that's what happening in my tests I think, hence the broken frame pacing
19:21 paulgdpr: I know wayland protocol proposals take forever, and FRR displays are on the way out.. So I guess I'll stay impossible to implement
19:23 MrCooper: not impossible, doesn't magically happen on its own though
19:23 paulgdpr: The steam deck is FRR I think... Maybe thanks to valve, it might be possible
19:25 paulgdpr: MrCooper: I'm afraid of taking the responsability of starting such a proposal because the day I replace my screen vith VRR I'll loose all interest in the idea
19:25 zamundaaa[m]: Adding another enum value to tearing control would be a really properly trivial thing
19:26 MrCooper: that's not enough for the compositor to make the call
19:26 zamundaaa[m]: In combination with commit timing it is
19:27 paulgdpr: zamundaaa[m]: and presentation_feedback already has a `seq` number which I guess is the equivalent of MSC on X11
19:28 MrCooper: so now commit-timing is good enough, eh :) then I'm not sure why the new enum would be needed though
19:30 paulgdpr: so the client could say "present this frame at this vblank number, or ASAP teared" ?
19:30 MrCooper: set the commit-timing constraint to start of vblank and the tearing hint?
19:32 zamundaaa[m]: MrCooper: commit timing right before vblank, like it is now, + a flag to say that if it misses the target, tearing is allowed
19:32 paulgdpr: I guess it works, but it still feels weird to say "present this frame by tearing it exactly at the time of vblank"
19:32 zamundaaa[m]: Which is different from the async flag, because that always allows tearing
19:33 MrCooper: zamundaaa[m]: that's just the existing tearing hint, since the presentation can't happen before the commit-timing constraint
19:34 zamundaaa[m]: MrCooper: I didn't mean the timestamp, but the vblank after it
19:34 paulgdpr: I personnaly prefer zamundaaa[m] solution, extend the meaning of the tearing hint, to be able to say "tear only if after this vblank". It sounds better because this hint is already optional
19:37 MrCooper: zamundaaa[m]: if the commit-timing constraint is set to the start of vblank, the only two possibilities are presentation without tearing at the end of vblank, or with tearing later
19:38 MrCooper: so the new enum is pointless
19:39 MrCooper: actually it's the same for any constraint inside vblank
19:40 zamundaaa[m]: MrCooper: it's not set to the start of vblank but some time before, because the timing isn't that precise in practice
19:42 zamundaaa[m]: And I wouldn't like to extrapolate per-output / presentation target information in the compositor from the client's per-surface timestamp
19:42 MrCooper: doesn't matter, the compositor can round any constrain in vblank to the end of vblank and handle it appropriately
19:43 MrCooper: same as it would with the new enum
19:43 zamundaaa[m]: Again, it's not in vblank. IIRC Mesa puts it 500us before
19:43 MrCooper: that can be changed for FIFO_RELAXED
19:44 MrCooper: or regardless really
19:45 MrCooper: without the tearing hint, any constraint within a refresh interval before the end of vblank boils down to the same thing
19:45 zamundaaa[m]: The presentation timestamp isn't at an exact enough cadence for that
19:45 MrCooper: not sure what that means
19:47 paulgdpr: I don't think timestamp can be used, only the "output's vertical retrace number": https://wayland.app/protocols/presentation-time#wp_presentation_feedback:event:presented:arg:seq_hi
19:47 zamundaaa[m]: On my 120.00Hz monitor, the difference between two presentation timestamps isn't exactly 8333us, it fluctuates a bit
19:47 MrCooper: zamundaaa[m]: ah, I guess you mean presentation times varying by a millisecond or more with drivers without proper DRM timestamp support? In which case, well use a proper driver :)
19:48 MrCooper: with AMD & Intel I'm seeing very little variance, within the duration of vblank
19:48 MrCooper: usually single-digit microseconds
19:48 zamundaaa[m]: MrCooper: no, I mean that it fluctuates with amdgpu
19:49 MrCooper: huh, not seeing that
19:49 zamundaaa[m]: Next thing ofc the client then needs to know the duration of vblank, and the compositor needs to try to infer meaning out of the client-set timestamp and past presentation timestamps
19:51 zamundaaa[m]: Let's just not do that. There's really no reason not to do a proper flag for a different presentation mode
19:52 MrCooper: alright
19:52 MrCooper: I didn't realize the client currently can't know the duration of vblank
19:53 paulgdpr: zamundaaa[m]: I just saw your work on Kwin, so yeah, you're really the guy to talk to about wayland compositors :)
19:56 MrCooper: zamundaaa[m]: FWIW, per the discussion starting at https://gitlab.gnome.org/GNOME/mutter/-/work_items/4022#note_2832062 , the variance you're seeing might be due to the monotonic clock ticking at varying frequency
20:10 zamundaaa[m]: paulgdpr: MrCooper too, he works on Mutter
20:11 zamundaaa[m]: MrCooper: makes sense. Still needs to be dealt with unfortunately
20:11 paulgdpr: oh wow <3 Thanks for you great work both then! I couldn't find MrCooper on Google