09:14electricworry: Been directed here from another channel. Does anyone know of a good IRC channel or forum where discussion technical discussion of A/V internals (CEC, EDID, etc.) would be appropriate?
10:25dj-death: what's the array_wildcard for in deref type?
12:26tzimmermann: sima, FYI i played with making DRM_IOCTL_WAIT_VBLANK fail on vblank timers. but user space requires the ioctl to work (even the queue waiting).
12:28sima: hm, so how does this work then with the drivers that don't support vblank?
12:29sima: tzimmermann, I guess might be good to document the defacto uapi with some references to which userspace you've tested
12:29sima: maybe in the kerneldoc for the relevant ioctl? I think we have some stuff there already
12:29sima: and get it acked by a bunch of compositor people
12:30tzimmermann: sima, if there's no vblank support, userspace will page-flip ASAP
12:31tzimmermann: with vblank support, userspace waits in the ioctl for vblank completion AFAIU
12:31sima: tzimmermann, yeah, but all of them or just some?
12:32tzimmermann: all i know of (gnome, kde)
12:32sima: ok, yeah that's a lot of them for sure
12:32sima: emersion, ^^?
12:32sima: tzimmermann, but yeah let's make the defacto uapi de jure and document what it is
12:32sima: at least we've learned something, yay
12:33sima: MrCooper, I guess that means mutter has a very special case for the nvidia driver, or has that one gained vblank support meanwhile?
12:33tzimmermann: ruling out vblank timers in the ioctl make userspace behave as in the no-vblank case. animation speed and frame rates are way off
12:33sima: yeah, that's no good
12:37MrCooper: mutter doesn't "page-flip ASAP" because the vblank ioctl fails, it waits for the previous atomic commit's completion event for that
12:38tzimmermann: MrCooper, ok, but that is effectively ASAP
12:38MrCooper: i.e. the important thing is that atomic commits don't complete unthrottled, not the vblank ioctls
12:39MrCooper: that's the problem then
12:39tzimmermann: MrCooper right
12:39MrCooper: (specifically atomic commits without the ASYNC flag)
12:40MrCooper: when I checked KWin code recently, it didn't use the vblank ioctls at all, so I suspect it's the same there
12:42tzimmermann: let's be clearer then: gnome 50 on my test system apparently requires this code to work correctly: https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L1841 12:42tzimmermann: otherwise it's either run too fast or not drop frames; depending on the workload
12:43emersion: yeah, i think only weston and mutter use DRM_IOCTL_WAIT_VBLANK
12:43MrCooper: and Xorg drivers
12:44pq: Weston uses DRM_IOCTL_WAIT_VBLANK only in a completely non-blocking way.
12:44pq: that is, to query the timestamp of the last vblank
12:44MrCooper: tzimmermann pq: same with mutter, it doesn't rely on the vblank ioctl for throttling
12:46tzimmermann: i just tested it 15 min ago. if you don't believe me then try for yourself
12:46MrCooper: I'm quite familiar with how mutter uses the vblank ioctl
12:46tzimmermann: for drivers with vblank timer, I returned an error right from here: https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L1835 12:46zamundaaa[m]: MrCooper: indeed. KWin only uses page flip events
12:46tzimmermann: MrCooper, i don't doubt your expertise
12:49pq: https://gitlab.freedesktop.org/wayland/weston/-/blob/ddd1cf6f3940a49c4aa5b6e82ba23888a6270d78/libweston/backend-drm/drm.c#L1083 is the only call to wait vblank in Weston.
12:49MrCooper: tzimmermann: mutter always passes 0 for request.sequence, so it can't hit the waiting case in the kernel
12:50MrCooper: tzimmermann: you can change mutter behaviour if you make the kernel artificially wait anyway, but that just masks the actual problem: unthrottled atomic commit completion
12:54MrCooper: completion of atomic commits without the ASYNC flag must be throttled to the refresh rate
12:56pq: Weston also always passes request.sequence = 0, and expects atomic commit completion to be throttled.
12:58pq: ..except when it uses the ASYNC flag, asking for tearing.
12:59mahkoh: tzimmermann: I have a hard dependency on DRM_IOCTL_CRTC_QUEUE_SEQUENCE for frame pacing. What you said above suggests that you're only working on drm_wait_vblank_ioctl and even there only on the blocking case. But if you were to also disable the QUEUE_SEQUENCE ioctl for some drivers that would be a big regression.
13:01MrCooper: it's largely the same kernel code
13:06jannau: pacing of commits and timestamps in page flip events is the only thing the apple KMS driver provides. As far as I'm aware that works with every compositor
13:07jannau: the only possible failure is that the compositor commits too late and effectivly present at 1/2 display refresh rate
13:09mahkoh: DRM_IOCTL_CRTC_QUEUE_SEQUENCE is required to determine the time of the previous vblank when the compositor was previously idle. On drivers where that doesn't work, primarily DRM_IOCTL_CRTC_QUEUE_SEQUENCE, it can be emulated by submitting dummy page flips.
13:09mahkoh: *primarily Nvidia
13:10pq: mahkoh, oh? Sounds like Weston uses WaitVBlank for the exact same thing. What's the difference?
13:12mahkoh: pq: I use DRM_IOCTL_CRTC_QUEUE_SEQUENCE to get a continuous stream of these events. These events are delivered via the same path that delivers page flip events.
13:12pq: ah
13:12pq: WaitVBlank is an immediate query, used in Weston as needed only
13:14pq: that is, when Weston starts repainting after being idle on a CRTC
13:17MrCooper: pq: in a nutshell, DRM_IOCTL_WAIT_VBLANK is the old weird thing with 32-bit sequence numbers, DRM_IOCTL_CRTC_GET/QUEUE_SEQUENCE the corresponding new(er) shiny thing with 64-bit sequence numbers
13:17MrCooper: s/thing/UAPI/
13:19MrCooper: mahkoh: "continuous stream" sounds like jay might be keeping the vblank interrupt enabled on idle systems, wasting some energy
13:21mahkoh: I've heard that before but I don't know how much of an impact that has.
13:22mahkoh: How does drm_wait_vblank_ioctl work if the interrupt was previously disabled?
13:23mahkoh: In non-blocking query mode.
13:23MrCooper: the driver keeps track how many refresh cycles passed using HW registers
13:24alyssa: karolherbst: any idea why cl cts is crashing inside spirv translator linking now?
13:24mahkoh: Disabling the DRM_IOCTL_CRTC_QUEUE_SEQUENCE stream after the system has been idle for, say, 30 seconds could be a possible improvement.
13:25MrCooper: the timestamp is extrapolated based on the current scanout position
13:25karolherbst: alyssa: what kind of crash?
13:25alyssa: #0 0x00007ffff78a8280 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<true>(char const*, unsigned long) ()
13:25alyssa: from /lib64/libSPIRV-Tools-link.so
13:25alyssa: #1 0x00007ffff78baabf in spvtools::Link(spvtools::Context const&, unsigned int const* const*, unsigned long const*, unsigned long, std::vector<unsigned int, std::allocator<unsigned int> >*, spvtools::LinkerOptions const&) () from /lib64/libSPIRV-Tools-link.so
13:25alyssa: i'm dnf upgrading now just in case
13:25karolherbst: mhhh
13:25karolherbst: sooo
13:25alyssa: uh oh
13:26karolherbst: SPIRV-Tools isn't ABI backwards compatible
13:26karolherbst: so you might have to rebuilt mesa to get new data layouts
13:27alyssa: awesome.
13:28karolherbst: yeah...
13:28karolherbst: I hope it's that issue, because last time I hit a crash, it was that issue :)
13:39alyssa: ok that fixed 'er
13:40alyssa: i will simply ask 0 follow up questions
13:40alyssa: thanks karolherbst
13:40karolherbst: np :D
14:04sima: tzimmermann, maybe I'm confused, with "no vblank support" I thought you mean just disabling the ioctl, but keeping the hrtimer vblank machinery internally in the driver so that atomic flips are paced to the refresh rate?
14:05sima: also just got two teeth fixed, my brain might be out on lunch still so to say
14:05tzimmermann: sima, that's what didn't work
14:07tzimmermann: as everything seem sot use the ioctl in no-block mode, we could disable the blocking for fake vblanks. but that would hardly make a difference in practice, i guess
14:09sima: tzimmermann, https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L1745 I was thinking of returning -EOPNOTSUPP for the hrtimer vblanks in that line
14:09sima: returning later on would be really confusing I think and not something any other driver would ever do
14:11sima: afaiui this should match the behaviour that the nvidia blob does
14:11sima: and I think the apple driver
14:11sima: essentially no vblank support, but page flips are still rate limited to refresh rate
15:15linkmauve: Hi, I just built Mesa master on my iBook G4 with an ATI Radeon Mobility 9550, but now Weston doesn’t even start with the DRM backend: https://linkmauve.fr/files/g4-weston.log 15:15linkmauve: I guess because of some little/big endian issue.
15:16linkmauve: Even the constant seems reversed, 0x34324142 reads little-endian to me.
15:17linkmauve: With --use-pixman, weston starts up but the colours are reversed.
15:17linkmauve: But that’s irrelevant to the issue at hand.
15:22linkmauve: I can only use XRGB8888 or ARGB8888, according to drm_info.
15:24linkmauve: On big-endian, XRGB8888 always means bytes are in the X, R, G, B order, right, no matter the API?
15:25linkmauve: Oh, and on boot, I get this one line too: [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a bios ROM
15:25linkmauve: Where could I find said bios ROM?
15:26linkmauve: I do have linux-firmware-radeon installed, with /usr/lib/firmware/radeon/R300_cp.bin.zst which should perhaps be it?
15:27tzimmermann: sima, i tried this, but it doesn't work
15:28MrCooper: linkmauve: there's no universal definition of what "XRGB8888" means, it depends on how the API defines it
15:29tzimmermann: sima, i also tried returning from https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L1835 , so that it could possibly call drm_queue_vblank_event() from 2 lines before
15:29tzimmermann: that doesn't work either
15:29MrCooper: linkmauve: it's about the x86 BIOS ROM on discrete graphics cards or x86 laptops, i.e. in your case probably a red herring
15:30linkmauve: Ok.
15:31MrCooper: tzimmermann: what does "doesn't work" mean exactly? What happened?
15:32MrCooper: tzimmermann: the nvidia driver always returns an error from the vblank ioctl, and it works fine with mutter; the same is apparently the case with asahi
15:34tzimmermann: MrCooper, when the ioctl returns an errno code, my user space (gnome 50) page flips as soon as frames are ready. it also doesn't drop frames when the output is too slow for the refresh rate
15:35MrCooper: I just explained that above
15:35MrCooper: the vblank ioctl returning an error isn't the fundamental issue
15:36tzimmermann: MrCooper, by "explained" you mean that the atomic commits complete unthrottled
15:36tzimmermann: ?
15:36MrCooper: yep
15:37tzimmermann: this would indicate an issue with the vblank timer's code, i think
15:41tzimmermann: but that code does work when the ioctl is present. and it's fairly straight formard. i'm confused...
15:41tzimmermann: 'forward'
15:46MrCooper: can the code which returns an error for the vblank ioctl get called for an atomic commit?
15:47sima: yeah if the hrtimer vblank code works, atomic flips should be throttled or there's a really strange bug somewhere
15:47sima: hm
15:48sima: nah, crtc_commit.flip_done should be signalled from the fake vblank, and that /should/ throttle the atomic commit machinery even if userspace submits the next one right away
15:59tzimmermann: we fire an hrtimer at the display refresh rate and call drm_crtc_handle_vblank() from the callback. that's minimal standard behavior. see https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L2195 15:59MrCooper: could it be that it allows "catching up" after a period of no atomic commits for some fake vblank intervals?
16:05tzimmermann: MrCooper, not sure. the only other meaningful code is in get_vblank_timestamp
16:05tzimmermann: code is at https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L2285 16:06tzimmermann: we return the current time is vblanks are disabled. that seems questionable
16:06tzimmermann: s/is/if
16:08tzimmermann: but the vblank core does the same https://elixir.bootlin.com/linux/v7.0.6/source/drivers/gpu/drm/drm_vblank.c#L897 16:12MrCooper: I think that generally doesn't fall back just because the vblank interrupt is disabled with HW drivers
16:13MrCooper: I mean drivers with full vblank support
16:16MrCooper: I guess get_scanout_position is NULL in drm_crtc_vblank_helper_get_vblank_timestamp_internal in your case?
16:16MrCooper: might need to fake that as well
16:27tzimmermann: MrCooper, i'll try that. thanks
16:33tzimmermann: MrCooper, just looked over the code again. vblank timers don't use drm_crtc_vblank_helper_get_vblank_timestamp_internal
16:35MrCooper: I see, then it looks like the fallback to ktime_get could explain it
16:36MrCooper: probably need to extrapolate from the last known timestamp
16:37MrCooper: in drm_crtc_vblank_get_vblank_timeout
16:37MrCooper: or in drm_crtc_vblank_helper_get_vblank_timestamp_from_timer
18:29sima: MrCooper, unless we have some bug that fallback should just result in some more timestamp jitter
18:29sima: like on all the other drivers that don't have a hw timestamp register or some other way to correct the timestamp you get when the interrupt fires
18:30sima: so yeah would be nice if hrtimer vblanks use the super accurate timestampe we can compute, but it shouldn't result in anything big going wrong
18:30sima: plus I don't see how disabling the vblank ioctl changes anything of relevance
19:34zmike: eric_engestrom: re: !39176, I don't think this is actually legal? you end up with -DHAVE_RENDERDOC_INTEGRATION=true in the cppflags and then in the c code you have #if HAVE_RENDERDOC_INTEGRATION which becomes #if true
19:50eric_engestrom: zmike: you're right, there's a `.to_int()` missing
19:50eric_engestrom: I'm on my phone, but if you post that change I'll r-b it
19:54zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41519 19:54zmike: not sure how nobody saw this before
20:07eric_engestrom: I'm wondering the same thing 🤔
20:14dwfreed: true evaluates to 1 in C23
20:14dwfreed: "Any identifier, which is not literal, non defined using #define directive, evaluates to 0"
20:15dwfreed: (except true as of C23)
20:31dwfreed: oh, also it works if <stdbool.h> is included before you try to use 'true' (because it's a #define)