06:48 tzimmermann: sima, jani, vsyrjala: hi. i find myself converting drivers to use a vblank timer. maybe we should make it the default for all CRTCs without vblank handling. this would enabled correctly timed vblank events for all of them. thoughts?
06:49 sima: tzimmermann, I guess it's a bit an uapi question, originally for these the idea was that userspace was supposed to be able to cope
06:49 sima: and essentially also be able to rely on vblank timings being real
06:49 sima: if we fake them everywhere that's gone
06:51 tzimmermann: background is that gnome (and others?) relies on the mode's refresh rate for its animation. they now actively backlist hardware without correct vblank
06:51 tzimmermann: sima ^
06:51 sima: lol
06:51 sima: or well, sad
06:52 tzimmermann: that's why we have vblank timers in the first place, i think
06:52 sima: yeah I guess if userspace decided to just change the uapi, or not bother with hw that just does not have vblank timers, we need to fake it
06:52 sima: and if we do, better do it consistently across the board
06:54 tzimmermann: i guess i can come up with a patch for that.
06:54 sima: might be good to get acks from other compositor folks though, to make sure we're not breaking their stuff
06:54 tzimmermann: good point
06:55 sima: tzimmermann, also, that gnome blacklist, is it an actual driver list, or do they detect properly whether vblanks are supported and just refuse to work?
06:56 sima: if the issue is that drivers badly faked vblanks instead of not supporting them, then that'd be a kernel bug
06:56 sima: another fun one would be to just fake something if the process is mutter
06:57 sima: also I think an ack from airlied would be good to confirm rh-internal that the gnome team really just decided to unilaterally force an uapi change or so
06:57 tzimmermann: it's not a bogus IRQ handling. i know that gnome disables efidrm, for example. with the gem BOs on fully cached shmem, display updates are fast. so the desktop animations rush way too fast
06:58 sima: yeah, it works like any other virtual display
06:58 sima: more or less
06:59 sima: so I'm kinda surprised gnome stopped working on these
07:00 sima: tzimmermann, oh also, did that already land for some drivers? can't find anything quickly
07:00 tzimmermann: writing out damaged areas to vram slows down things a bit, but it's still fast. On fully virtual displays where even the vram is cached, there's nothing throttling the desktop update. everything rushes with several hundred FPS, burning CPU cycles
07:00 sima: or did you mean that you've started looking into this
07:01 sima: yeah, don't do that :-P
07:01 emersion: hm, what are we supposed to do on these drivers?
07:01 sima: realize there's no vblank even support, use your own timer to throttle the event loop
07:02 sima: iirc that's the uapi contract, without vblank event support expect free-wheeling flips because it's some funny virtual thing
07:02 emersion: i haven't seen code about this anywhere tbd
07:02 emersion: tbh
07:02 tzimmermann: all drivers for virtual gpus (bochs, cirrus, vmwgfx, virtgpu) now use vblank timers
07:02 sima: oh
07:03 tzimmermann: sima, "use your own timer" was my argument, but that didn't count in user space
07:03 emersion: also drmCrtcGetSequence throwing ENOTSUP is quite annoying to handle
07:03 tzimmermann: now with timers, everything works nicely
07:03 emersion: how can one detect lack of vblank events?
07:04 tzimmermann: also, vmwgfx has had their own implementation of vblank timers since ages. so it's not a new thing
07:04 tzimmermann: emersion, you can't directly
07:05 emersion: better question: how do i know that i need to set up a timer?
07:05 tzimmermann: emersion, there's always a vblank event. the question is whether it is synced ot the actual display frequence, or comes whenever it's ready
07:05 emersion: right
07:05 emersion: i remember something about vkms and this
07:06 tzimmermann: vkms has had timers too
07:06 emersion: yeah, but optional iirc
07:06 emersion: so, how do i know vblank comes immediately?
07:06 sima: yeah, the entire point of making timers in vmks optional was so that compositors could test against it
07:06 emersion: also, any downsides to just do the timer thing in all drivers lacking vblank?
07:06 tzimmermann: emersion, user space should always set up a separate timer, and trigger a display update from there
07:07 emersion: isn't that racy?
07:07 emersion: hm, wait for timer + vblank event?
07:07 tzimmermann: emersion, you cannot detect vblank interrupts directly AFAIK. if the vblank event is synced to the display refresh, it's event triggered. otherwise it's best-effort
07:08 sima: tzimmermann, the entire pile of vblank related ioctl don't work if you have virtual hw
07:08 tzimmermann: emersion, there are no direct drawbacks from vblank timers; except that we'd make vblank timing a guarantee of the UAPI
07:08 sima: or well, this is how it was supposed to work
07:08 sima: I guess we've done the uapi change last oct
07:09 sima: tzimmermann, yeah I think since we're here doing this generically would be much better
07:09 emersion: +1
07:09 sima: so zero code in drivers if they don't support vblanks
07:10 sima: since that also gives us the option to disable/detect that, if it's an issue anywhere
07:10 tzimmermann: ok, i see. i'll come up with a patch then.
07:10 sima: not very optimistic about compositors being able to cope with different hw if we continue on this trajectory, but oh well
07:10 emersion: sima, you mean you've gated all vblank IOCTLs behind a check, and you bail out with an error if the driver doesn't support vblank?
07:11 sima: yes
07:11 sima: it's been how this worked the previous decade plus of kms
07:11 emersion: hm that might explain why drmCrtcGetSequence fails and causes pain
07:11 sima: but I guess no one cared enough
07:11 sima: lol
07:11 sima: yeah it's an optional feature that indicated some pretty important aspect of the drm driver
07:12 sima: if compositors yolod it all by short-circuiting the composition loop, then oops, here we are
07:12 tzimmermann: :(
07:13 tzimmermann: i think, user space generally tests only with the big vendors, which all support nice features
07:13 sima: yeah
07:13 sima: which is why vkms had it as an option, but oh well
07:14 emersion: wlroots doesn't have any timer for sure
07:14 sima: userspace has spoken :-/
07:14 sima: just need to make sure we also crawl around in uapi docs, I've thought I've documented that somewhere once
07:14 emersion: weston has a timer, but only for detecting when a page-flip event never comes
07:14 sima: or at least explained it a loooot of times
07:14 emersion: ie, the timer is disarmed when the page-flipe event comes
07:14 sima: kwin?
07:15 emersion: cc zzag
07:15 emersion: cc jadahl
07:15 tzimmermann: but there's another problem: if the bus is too slow, it will throttle user-space animation. is this being handled correctly?
07:15 tzimmermann: emersion ^
07:15 sima: I'd expect kwin to not suck because there's no vblank on the asahi driver afaik
07:15 emersion: hm, asahi works fine in wlroots
07:15 emersion: afaik
07:15 emersion: do they not have a timer?
07:16 sima: emersion, iirc it rate limits page flips though, just no vblank events
07:16 sima: which is the thing that this will horrendously break
07:16 sima: I guess
07:16 emersion: hm, we (compositors) mostly only rely on page_flip events, afaik
07:16 sima: xorg uses the events for frame scheduling iirc
07:17 emersion: ah, but the libdrm side doesn't quite look like the UAPI side
07:17 sima: tzimmermann, so maybe we should have pageflip timer but not vblank events for the virtual ones?
07:18 sima: meaning it's still opt-in, but just a flag, and we at least fail the ioctl still?
07:18 sima: essentially a "please ratelimit my flips" thing
07:18 emersion: none of wlroots, weston, kwin, mutter use DRM_EVENT_VBLANK
07:18 tzimmermann: sima, do you really think, any one will care about that flag?
07:19 emersion: all of them use DRM_EVENT_FLIP_COMPLETE
07:19 sima: tzimmermann, I meant kernel-internally so that we don't pretend the vblank ioctls actually do something useful
07:19 emersion: tzimmermann: re slow bus, not sure i understand
07:20 sima: emersion, does anyone call the vblank ioctl at all?
07:20 tzimmermann: sima, i think we can detect this automatically
07:20 emersion: which IOCTL?
07:21 sima: tzimmermann, I'm wondering about the asahi driver mainly, because that one doesn't have vblanks but probably doesn't want fake ones either
07:21 sima: but I guess we can put the onus of adding that flag on that driver
07:21 emersion: DRM_IOCTL_WAIT_VBLANK?
07:22 sima: DRM_IOCTL_WAIT_VBLANK DRM_IOCTL_CRTC_GET_SEQUENCE DRM_IOCTL_CRTC_QUEUE_SEQUENCE
07:22 sima: I think these three should fail if we have faked vblanks
07:23 emersion: weston uses DRM_IOCTL_WAIT_VBLANK to figure out when it is in the cycle (how much time left until next vblank when unpausing the render loop)
07:23 emersion: libliftoff uses DRM_IOCTL_CRTC_GET_SEQUENCE
07:23 tzimmermann: emersion. when the driver writes to a slow bus, the atomic commit will take a long time, thus slowing down the generation of best-effort vblank events.
07:24 tzimmermann: userspace should see less events than the display mode's frequency. hence the animation runs slower
07:24 sima: emersion, but no fallback to an internal timer to rate-limit the animation?
07:24 tzimmermann: no idea if that works correctly.
07:25 sima: tzimmermann, we can always miss flips, userspace has to cope
07:25 sima: we shouldn't, but under real load that's just what happens
07:25 jadahl: tzimmermann: what denylist are you referring to?
07:26 tzimmermann: sima, of course, we cannot do much about it. but does userspace care? i did some tests with slow USB and it seems ot work. still i'm not overly confident
07:26 sima: tzimmermann, yeah, but that's defo not something we can fix in the kernel
07:26 tzimmermann: jadahl, you told me that some animation features are disabled on efidrm, IIRC
07:27 jadahl: the only thing we do is disable animations when there is a software renderer
07:27 tzimmermann: i see. that wasn't about the actual driver.
07:28 emersion: tzimmermann: should be fine, i think weston shows a warning but that's about it
07:28 tzimmermann: emersion, got it
07:28 jadahl: no, and its not anything about vblank, but because it's considered a better experience when the renderer is software based thus relatively slow
07:28 emersion: tzimmermann: could the bus operations be done in a separate kthread?
07:29 tzimmermann: emersion, not really. it would just pile up bus writes
07:29 tzimmermann: jadahl, how do you deal with hardware being too slow?
07:29 emersion: right, you really want to throttle user-space frames after all
07:29 jadahl: also iirc we have handled lack of vblank timings because nvidia driver doesn't get us any timestamps (in the past)
07:29 emersion: makes sense
07:30 jadahl: tzimmermann: drop frames
07:30 tzimmermann: jadahl, i see. makes sense
07:30 emersion: jadahl: lack of timing is different from lack of event though
07:30 jadahl: true
07:30 jadahl: I guess we do depend on a page flip callback if we ask for one
07:32 jadahl: is the question about drivers wanting to not pass those callbacks?
07:33 emersion: yes
07:33 emersion: well
07:33 emersion: about drivers sending a page-flip event immediately
07:33 sima: it just completes right away
07:33 emersion: jadahl: current kernel expectation is that user-space sets up a timer and waits for more time if the event comes in immediately
07:34 sima: and userspace was supposed to realize this is up by noticing that the vblank ioctls refuse to work
07:34 emersion: jadahl: but we're discussing making the kernel set up the timer instead
07:34 sima: emersion, well it's actually detectable, no guesswork needed
07:34 emersion: sima, but we don't use vblank ioctls for the most part
07:35 MrCooper: sima: unfortunately, with the nvidia driver, atomic commit completion events work properly, the vblank ioctl doesn't though
07:36 sima: emersion, hm, that didn't happen because asahi essentially required relying on the page flip counter?
07:36 sima: MrCooper, ah so there's another one
07:36 sima: not just asahi
07:36 jadahl: why not pass a 0 timeval in the flip event to not pretend the values are sensible?
07:36 MrCooper: i.e. your dichotomy doesn't work
07:36 sima: MrCooper, pretty sure the nvidia driver is newer than the og uapi
07:37 MrCooper: unfortunately they don't care about the rules
07:37 sima: but yeah sounds like everyone just adopted that
07:37 sima: oh yeah I understand the reality here
07:38 sima: just trying to figure out what the uapi should be, leaning towards faking events for pageflip but not supporting the actual vblank ioctls in that case
07:38 sima: which would be in line with nvidia and asahi drivers
07:38 sima: which is something userspace actually tests against
07:39 MrCooper: yeah that "works" (in the sense of being able to limp along) for mutter
07:39 emersion: what is the motivation for making vblank ioctls fail?
07:39 emersion: would these be hard to fake?
07:39 sima: it's more that they're fake
07:40 emersion: if page_flip event is fake, then you need a seq anyways
07:40 sima: and we can't fake them on nvidia and asahi easily
07:40 MrCooper: fake timestamps can make things worse
07:40 sima: yup this
07:40 sima: just worrying about more fallout
07:40 jadahl: what drivers reply immediately with timeval set to "now"?
07:40 MrCooper: mutter 50.0 tried to extrapolate from pageflip completion event timestamps with the nvidia driver, users complained about more frame drops
07:41 sima: jadahl, before oct 2025 all the ones that did not support the vblank ioctl listed above
07:41 sima: pretty much everything virtual (minus vmwgfx) and some of the other simple drivers
07:41 jadahl: vmwgfx, virtgpu, cirrus, ..
07:41 jadahl: afaik gnome works on those
07:41 sima: MrCooper, yeah I feel like if we try to fake timestamps, bad stuff will happen
07:41 sima: there's always jitter
07:42 sima: jadahl, I'm wondering whether it once worked and it broke in an effort to support nvidia
07:42 sima: which would be lol, but oh well
07:42 jadahl: not impossible
07:42 MrCooper: jitter was indeed the issue there, it was more than a millisecond on some systems
07:42 emersion: jadahl: maybe it worked but the render loop was a busy loop?
07:42 sima: or that
07:43 MrCooper: shouldn't be a busy loop, mutter schedules frames based on refresh rate
07:43 jannau: the apple KMS driver does not have vblank timers but it has blocking atomic commit and page flip events. That combination has worked fine. We don't have have direct access to the vblank irq
07:43 sima: anyway, virtual vblank timers it is in one shape or another, thanks nvidia
07:44 sima: MrCooper, tzimmermann said above that it falls apart though and that's why we've added the timers?
07:45 MrCooper: would need to know more details about how it falls apart
07:45 tzimmermann: MrCooper, here's the original bug report I got: https://bugzilla.suse.com/show_bug.cgi?id=1189174
07:46 MrCooper: it can be a busy loop if a frame update is expected to take longer than a refresh cycle
07:46 tzimmermann: on virtual devices, the page flip happens way too fast. and because there's no vblank irq, it is not throttled/sync/etc to the display refresh
07:46 tzimmermann: so the compositors immediately schedule the next frame, and so on
07:47 tzimmermann: even moving the mouse burns cpu cycles for displaying hundreds of FPS
07:47 tzimmermann: that can happen on any hardware without IRQ. virtual devices are just the most obvious
07:48 MrCooper: what's the refresh rate according to the DRM mode?
07:48 tzimmermann: hence, my initial question here was if we'd want to throttle the event signaling to the display refresh for all drivers that do not have a vblank IRQ
07:49 tzimmermann: something like 60 hz
07:49 tzimmermann: the devices use regular VESA modes AFAIK
07:49 MrCooper: then mutter should do at most 60 updates per second
07:50 tzimmermann: that was my original argument
07:50 MrCooper: unless the timestamps it gets are significantly in the past maybe
07:50 tzimmermann: and everyone was like "no, fix the drivers"
07:50 tzimmermann: here's the kwin bug report: https://invent.kde.org/plasma/kwin/-/merge_requests/1229#note_284606
07:51 MrCooper: if the compositor can't sustain frame rate equal to refresh rate, maxing out the CPU is kind of expected
07:52 tzimmermann: MrCooper, the compositor refreshes too fast
07:52 tzimmermann: not too slow
07:52 MrCooper: define "too fast"
07:53 jadahl: I assume "too fast" here means e.g. 80 fps instead of 60 on a 60 hz mode
07:53 MrCooper: is the compositor frame rate higher than the DRM mode refresh rate?
07:53 tzimmermann: several hundred FPS. as soon as a pageflip completes, it sends the next one, and the next, end the next, and so on
07:53 tzimmermann: yes
07:54 MrCooper: sounds like something might be going wrong in mutter, would need to investigate there
07:54 MrCooper: that is assuming the timestamps it gets are "reasonable"
07:54 tzimmermann: this apparently effect all compositors. these bug reports are against kwin, for example
07:55 MrCooper: is it the same with mutter?
07:55 jannau: judging from Plasma's login animation it's more like 600 fps instead of 60 on fast devices with simpledrm
07:55 tzimmermann: MrCooper, yes
07:55 tzimmermann: jannau, exactly the problem
07:56 jadahl: MrCooper: I suspect the timestamps we treat as "presentation time" is just "now" and if we use them for anything like it, we'll schedule things incorrectly
07:57 MrCooper: then the next frame should be scheduled for "now + <lenght of display refresh cycle>", so that can't explain it
07:58 MrCooper: at least not with the deadline timer, though maybe that one's not working in this case?
07:59 MrCooper: anyway, taking a step back, to me it definitely makes more sense to handle this in the kernel, expecting all user space to handle this doesn't scale
08:01 MrCooper: at the very least, there would need to be some kind of signal by which user space can know that atomic commits don't actually follow the refresh cycle
08:04 jadahl: the timestamp 0 could be a good enough hint for that
09:00 MrCooper: instead of always reporting "now" for the timestamp in completion events, rounding them up to the next refresh cycle boundary (extrapolating from the previous completion event timestamp) might help with mutter
09:01 tzimmermann: i'll send out an RFC series for the kernel in a bit
09:52 MrCooper: tzimmermann: doing what?
10:22 zamundaaa[m]: MrCooper: the reason the issue caused fast rendering is that atomic commits aren't done at vblank but necessarily some time in advance. When the bug report was made, KWin did that close to the beginning of each refresh cycle
10:23 zamundaaa[m]: With newer KWin it should be better, but for a 60Hz display it would still result in maybe 65-70Hz rate
10:24 zamundaaa[m]: jadahl: a timestamp of zero also happens with drivers that do have vblank but can't, or don't report the timestamp
10:25 jadahl: zamundaaa[m]: like nvidia in the past
10:25 zamundaaa[m]: Still today afaik, with the fully proprietary kernel driver
10:25 jadahl: maybe one day...
10:26 zamundaaa[m]: Also amdgpu has bugs where it reports zero when you do cursor-only commits
10:28 MrCooper: zamundaaa[m]: right, and to me that's more an issue of the kernel not meeting the user-space expectations for this functionality, than those expectations being wrong
10:34 shivamklr: hi
11:15 blazz: hi all! I'm a newcomer. I'm interested in contributing to Mesa. Is there anyone who could give me some pointers on where to start? I'd like to give a hand however I can :)
13:22 Ermine: blazz: you can look through mesa's issues and see if you can fix something, or, even better, you can try to fix issues you've encountered on your machine
13:22 Ermine: Also you can run piglit test suites and see if there are any regressions
13:26 Ermine: It would be much easier for you if you have prior experience with OpenGL and/or Vulkan
13:41 Ermine:should start going through commit logs
14:21 zmike: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15365 RFC
14:39 alyssa: someone's feeling spicy
14:40 alyssa: zmike: It concerns me somewhat that no major distros ever packaged amber
14:40 zmike: I don't think amber and main could be installed side-by-side?
14:41 zmike: also I don't think anyone ever worked on amber
14:41 zmike: so not packaging it was the correct decision
14:41 alyssa: This isn't a -1
14:41 zmike: this isn't an argument
14:41 alyssa: just that if we do this we want to coordinate with our downstreams to make sure users of affected HW don't see interruption
14:42 alyssa: argumentclinic.mp4
14:42 zmike: if it's anything like the other big code moves I've done, there won't be any changes happening soon
14:44 karolherbst: zmike: I thought some distros did and that it worked with glvnd?
14:44 alyssa: this isn't an argument this is just contradiction
14:44 zmike: yeah it was distro-side if it was done
14:44 zmike: my proposal is that the installed files are by default non-conflicting
14:44 karolherbst: gentoo has packages e.g.
14:45 karolherbst: wait amber was 5 years ago? 😭
14:46 ccr: the structure of time has changed
14:46 alyssa: ....Geez was it now
14:47 alyssa: but I remember it and I'm still babygirl
14:47 zmike: I have no memory of it
14:47 zmike: just the results
14:47 alyssa: ("You've been in Mesa for 7 or 8 years alyssa" "Hnnnnnnn")
14:48 alyssa: zmike: looking back at https://docs.mesa3d.org/amber.html it looks like most of the affected hardware had replacement drivers in-tree so the incentive for distros to package was massively les than there would be here too
14:55 glehmann: what would be needed to make installing alongside mesa work beside renaming libgallium.so?
14:56 zmike: glx/egl renames
15:08 Sachiel: daniels: people are waiting on you for https://gerrit.khronos.org/c/vk-gl-cts/+/19625
15:11 daniels: Sachiel: yeah I know, just been busy with Mali stuff and also buying a new desktop which can build the CTS in less than a month
15:12 MoeIcenowy: Mesa not exposing GL_ARB_compatibility at all for OpenGL 3.1 seems to break kwin_wayland
15:12 MoeIcenowy: (because some compatibility codepath is triggered on 3.1 in Qt
15:25 shivamklr: Hey everyone, I am new around here. Is it common to discuss things about DRM, Sched in this channel?
15:26 MrCooper: welcome, yep