10:10 lucaceresoli: lumag: if you manage to have a look at https://lore.kernel.org/lkml/20260507-drm-bridge-alloc-getput-panel_or_bridge-v5-3-472b913b5cb7@bootlin.com/
10:11 lucaceresoli: it would be great if you could comment on the remark in the sashiko review: "Could the assignment of hdmi->next_bridge happen too late here?"
10:11 lucaceresoli: https://sashiko.dev/#/patchset/20260507-drm-bridge-alloc-getput-panel_or_bridge-v5-0-472b913b5cb7%40bootlin.com
10:12 lucaceresoli: The lifetime of the involved components is not clear to me, so I cannot say whether the issue pointed by sashiko is valid or not
12:51 tzimmermann: why do we still have DRM_IOCTL_WAIT_VBLANK ? isn't that only for user-space drivers?
13:03 MrCooper: no
13:04 MrCooper: it's there because it's used
13:09 tzimmermann: MrCooper. sure. i'm just surprised
13:09 MrCooper: why? :)
13:10 tzimmermann: i'd expect userspace to leave vblank sync entirely to the kernel. userspace would only send new page flips inregular intervals
13:14 MrCooper: tzimmermann: it's needed to know the latest vblank timings before doing a flip
13:15 MrCooper: e.g. after an idle period
13:16 MrCooper: the longer since the last flip, the less accurate extrapolation based on refresh rate becomes
13:17 tzimmermann: ok. i thought this was entirely done with events like DRM_EVENT_VBLANK and DRM_EVENT_PAGE_FLIP_COMPLETE
13:17 MrCooper: DRM_IOCTL_WAIT_VBLANK is what triggers DRM_EVENT_VBLANK
13:18 tzimmermann: oh, ok
13:18 MrCooper: what I described above works without events or blocking though, the ioctl can directly return the latest timings
13:20 tzimmermann: that's what happens when drm_wait_vblank_is_query() == true in the kernel?
13:25 MrCooper: yes
13:27 tzimmermann: oh, makes sense.
13:27 tzimmermann: thanks
13:33 MrCooper: no worries
13:35 MrCooper: (if anyone wonders about the weird DRM_IOCTL_WAIT_VBLANK UAPI, 24-years-ago me was just learning about that stuff :)
13:38 tzimmermann: sima, i've investigated the vblank-timers-for-everyone-by-default idea, but it turns out to be quite invasive. yet you wanted a flag that disables the vblank ioctl, right? that should be considerably easier
13:38 sima: tzimmermann, I'm honestly not sure what's best here ...
13:38 sima: it's just that exposing the vblank ioctl when we fake this stuff entirely feels icky
13:39 sima: least because there's big drivers like agx and nvidia blob that also don't expose the vblank stuff
13:42 tzimmermann: i see. it's not yet too late to disable the vblank ioctl for fake vblanks, I think. but i wonder if some compositors would fall back to the old behavior of spiking cpu loads
13:42 sima: so userspace should be able to cope
13:43 sima: tzimmermann, well if they do, then they'll also fail on the nvidia blob, which a lot more people seem to care about
13:43 sima: but yeah, really not sure
13:59 MrCooper: tzimmermann: the vblank ioctls shouldn't matter for spiking CPU loads, rather it matters that atomic commits don't complete at a higher rate than the CRTC mode refresh rate
14:00 tzimmermann: MrCooper, ok
14:01 tzimmermann: for reference, we've had vblank timers for a long time in vmwgfx and amdgpu already
14:02 tzimmermann: i'll investigate using a simple flag for disabling the ioctl. with that in place, we can use vblank timers where necessary without commiting to a uapi change
15:12 MoeIcenowy: tzimmermann: saying about DRM_IOCTL_WAIT_VBLANK, the implementation of that ioctl in drm_fb_helper is hardcoding to wait on crtc0
15:13 MoeIcenowy: and you duplicated this hardcode in drm_fb_helper_fb_dirty(), which isn't a rarely-used codepath...
15:13 MoeIcenowy: it seems that this is why I got WARN_ON on drm/loongson in my setup (because the internal LCD of my 3A4000+7A1000 laptop is on crtc 1)
18:40 lumag: lucaceresoli: yes, it seems it is correct.
19:28 robclark: karolherbst: so.. seems like more recent mesa build is having trouble finding opencl-c-base.h (debian).. I've an older build from bit over a month ago that is fine.. both linking against same llvm version (21.1).. I can't rule out something else having changed/upgraded in the mean time vs something that changed in mesa. Ring a bell?
20:01 lucaceresoli: lumag: OK, thanks for checking! A v6 will be needed then
20:27 BlueMatt: cmarcelo: sorry, yes, i did end up getting access to a fossilized set of shaders. i have a kinda decent branch for large grf but its not super exciting unless i can compare it to an upstream that is a bit more interesting so now i distracted myself working on the register allocator more generally (
20:28 BlueMatt: its sad some of the newer drivers, looking at you asahi, decided to go their own way and have more fun than the general one)
20:29 BlueMatt: anyway, will see if i get anything worth upstreaming, reducing spills/fills materially is easy, question is if its fast enough to be worth it
20:29 BlueMatt: in the mean time, any more thoughts on coopmat2-flex-dim?
21:59 karolherbst: robclark: not really.. the lookup paths are weird and I kinda want a more reliable solution there anyway, but I haven't really found a good way to improve the situation.
22:16 robclark: karolherbst: strace says it's actually finding the file... so like an include-path problem?
22:16 robclark: [pid 34996] openat(AT_FDCWD, "/usr/lib/llvm-21/lib/clang/21/include/opencl-c-base.h", O_RDONLY|O_CLOEXEC) = 4
22:33 karolherbst: robclark: yeah.. maybe? I kinda super dislike what we are doing inside clc_compile_to_llvm_module there for the resource path
22:34 robclark: it seems to be a regression.. although not sure why I don't have the same issue on fedora. I'm bisecting
22:34 robclark: or.. hmm, I think it is
22:41 karolherbst: maybe a clang update broke it
22:41 karolherbst: or rather.. packaging update
22:43 robclark: no, going back to an older mesa does seem to fix it..
23:05 robclark: https://www.irccloud.com/pastebin/xbDGj4d9/
23:06 robclark: karolherbst: ^^^ bisected to that.. reverting that fixes things somehow
23:47 karolherbst: ?!?
23:47 HdkR: !?!
23:48 karolherbst: robclark: with that patch applies, what's the difference in `clang_install_res_path`?
23:51 karolherbst: alternatively could get rid of any external C++ symbol in clc...
23:52 karolherbst: uhm.. external C++ stdlib symbol I mean
23:52 robclark: I can check in gdb... but after cts run finishes