07:40 MrCooper: sima: maybe it's something else, clearly there is some bug somewhere which prevents the throttling from working as intended though
07:42 tzimmermann: MrCooper, i think the calculation in the timer's get_vblank_timestamp is incorrect
07:43 tzimmermann: AFAIU it's supposed to return the timestamp of the first visible scanline after the most recent vblank irq.
07:44 tzimmermann: and the vblank timer's implementation always returns the timestamp of the last vblank timeout
07:44 tzimmermann: i'm still investigating, but that looks like a lead
07:45 MrCooper: another thing I notice is that drm_crtc_vblank_start_timer uses a relative timer with fixed interval, which presumably doesn't result in firing at regular intervals when the timer keeps getting enabled and disabled again?
07:47 MrCooper: might be better to use an absolute timer and keep extrapolating the target time when it fires
07:47 tzimmermann: that's also worth investigating
07:49 tzimmermann: IIRC the original implementation was for testing with vkms. likely these problems never materialized unless someone looks at a real display output
07:56 MrCooper: tzimmermann: I assume you're aware of this, just in case though: the timestamp can be in the future, if scanout is currently in a vertical blank region
07:56 tzimmermann: MrCooper, yes. with vblank timer, that timestamp is apparently never in the future
10:36 lucaceresoli: mripard: what's the plan with "[PATCH v4 0/2] drm: Rename drm_atomic_state"?
10:37 lucaceresoli: mripard: as it touches lots of files, shouldn't it be applied soon?
11:25 tzimmermann: lucaceresoli, it went directly into drm-next to make branch handling easier. see https://gitlab.freedesktop.org/drm/kernel/-/commit/5164f7e7ff8ec7d41065d3862630c2ba09854328
11:32 lucaceresoli: tzimmermann: ah, great, thanks!
11:51 mripard: lucaceresoli: it should be in drm-next, drm-misc-next and linux-next by now
12:37 lucaceresoli: mripard: indeed it is (at least drm-misc-next, definitely)
13:18 karolherbst: could one of the pvr developers confirm whether "pco_fmad" is fused or unfused?
13:19 karolherbst: and if it's fused, what's the internal precision?
13:33 tzimmermann: MrCooper, does screen mirroring affect the handling of vblanks or page flips in mutter?
13:37 MrCooper: shouldn't, mutter currently always uses separate CRTCs
13:54 tzimmermann: MrCooper, here's what i see: for testing, i use 2 cards: i915 and udl (i.e., vga on USB 2.0). the udl driver runs with vblank timers. both mirror a single screen. with the WAIT_VBLANK ioctl disabled, the udl device is extremely slow because mutter apparently doesn't drop any frames. with the ioctl enabled, it runs at regular speed.
13:55 tzimmermann: i have applied all the fixes and ideas we discussed for the vblank timer, but neither changes any of this.
13:55 tzimmermann: i can also run weston directly on the udl device and framerates and animation are as expected
14:04 pq: FWIW, Weston does still throttle somewhat, even if the KMS driver completes atomic flips immediately.
14:05 pq: It would still run at a significantly higher cadence than the refresh rate would imply.
14:05 MrCooper: the only effect the vblank ioctl can have is that the KMS thread sleeps for some time before the next atomic commit, so I'd expect the opposite correlation with "speed" if anything
14:06 pq: "extremely slow" could be queueing up lots of FBs, maybe? How does UDL work?
14:06 MrCooper: (assuming "speed" refers to frame rate)
14:07 MrCooper: pq: good point, that's plausible
14:07 pq: ISTR hearing that drivers like UDL would send the page flip event before the USB data transfer may have completed. Does it do that?
14:08 MrCooper: anyway, if atomic commits were throttled as intended, the atomic commit ioctl should do a similar sleep as the mutter KMS thread does with the vblank ioctl
14:09 MrCooper: pq: again sounds plausible
14:17 tzimmermann: MrCooper, that sleeping of the KMS thread is what appears to be missing
14:18 MrCooper: it's not required, so can't be "missing" :)
14:18 pq: in UDL atomic commit impl?
14:18 MrCooper: (from a UAPI PoV)
14:19 tzimmermann: wrt "speed": the speed of the animations is too slow because mutter doesn't seem to drop frames if the output is overloaded
14:20 pq: tzimmermann, is the page flip completion event rate matching the rate mutter is rendering at, or the rate the display is updating at?
14:20 MrCooper: tzimmermann: it does based on completion events, so maybe something like what pq mentioned above, udl sending the completion event before the USB transfer finishes
14:20 tzimmermann: pq, udl sends whatever user space commits. it packs up the framedata in USB URBs and sends them
14:21 tzimmermann: pq, can i see the page-flip event rate in weston somehow?
14:21 pq: tzimmermann, yes, but does it wait for the sending to finish before telling userspace to continue?
14:22 tzimmermann: pq, udl sends as fast as possible. the URB processing runs concurrently. if the USB bus is saturated, the kernel queues up frames
14:23 tzimmermann: pq, but the vblank timer limits the user-space page flips to a reasonable rate
14:23 MrCooper: tzimmermann: can you capture a mutter debug log as described in https://gitlab.gnome.org/GNOME/mutter/-/work_items/4782#note_2748389 ?
14:23 tzimmermann: unless i hit that problem
14:23 pq: tzimmermann, if you launch 'weston -l log,drm-backend', you should get a log flood that gives you timestamps and too much more. Best to redirect that to a file.
14:24 tzimmermann: i'll try these debugging options
14:24 pq: tzimmermann, "the kernel queues up frames" sounds like the culprit.
14:26 pq: tzimmermann, I think we still have not established whether UDL actually delays sending page flip completion events to match the hypoothetical refresh rate. Does it do that?
14:28 pq: If UDL just kicks a bunch of data towards USB and immeditely emits the page flip event, and the USB sub-system buffers all that data and gradually sends it out on its own pace, that would completely explain what you see.
14:29 pq: Ideally UDL should wait until both the USB data has finished draining and the vblank timer has ticked once before sending the page flip completion.
14:30 MrCooper: (side note: might not need to wait for the transfer to finish before sending the completion event, it does need to wait for it to *start* / the previous transfer to finish though)
14:30 pq: yes
14:31 MrCooper: similar to how the event is sent at the start of the corresponding refresh cycle
14:31 pq: indeed
14:51 tzimmermann: pq, yes, that makes sense. but why does it work when the wait_vblank ioctl is in place?
14:55 mahkoh: Compositors use vblank events for frame scheduling and frame pacing.
14:57 tzimmermann: pq, udl uses the regular pattern of many drivers: arm the event in atomic_flush and send it in the next vblank timeout
15:12 MrCooper: which should be fine as long as transferring a frame takes less time than a a refresh cycle
15:12 MrCooper: tzimmermann: the mutter KMS thread sleeping for some time when the vblank ioctl works may just happen to avoid the issue
15:20 tzimmermann: pq, MrCooper, i've added code to udl to trottle the framerate according to USB saturation. works nicely even without the ioctl available
15:21 tzimmermann: thanks for helping with that
15:21 MrCooper: no worries, glad we're homing in on the real issue
15:22 tzimmermann: well, calling the ioctl thing seems to have side effects as you said. IDK how else this could be related then
15:23 tzimmermann: i also have a number of improvements and fixes for the vblank timer, which i'll send out as well. also thanks for helping with that
15:23 MrCooper: keep in mind that KWin doesn't use the vblank ioctl at all, so nothing that ioctl does or doesn't do can matter for KWin
15:24 tzimmermann: the ioctl seems to be a false lead
16:09 simon-perretta-img: Other than f2fmp and co, nir doesn't have any other way of representing or decorating relaxed/medium precision for alu that I might be missing, does it?
16:14 simon-perretta-img: Never mind, on second thoughts I think I'm approaching this backwards
18:43 CounterPillow: Do we have an EDID editor yet that supports HDMI 2.x E-EDID stuff?
19:32 rpavlik: I'm not sure about any specific HDMI 2.x stuff, but I know I've done HDMI vendor extension blocks (like the HMD flag) with this tool i occasionally maintain. https://github.com/rpavlik/edid-json-tools
20:53 Ristovski: Venemo: I'd just like to say that your efforts on continued support for older hw and even backporting new-ish features to older hw are greatly appreciated, thank you.
21:38 Venemo: Ristovski: thank you, you're welcome!
23:35 ngcortes: howdy y'all, i'm wondering if there might be a kernel bug that's affecting bmg. intel mesa ci is seeing ~200,000 tests crashing on the anvil driver running vulkancts like 1/3 test suite runs.
23:36 ngcortes: I have an email drafted with what I think is the relevant info. is there a pdl I could send it to?