01:41zf: the futex wait was a misread on my part; I'm not sure where the broken timeout is but it seems to be the timeout passed to DRM_IOCTL_SYNCOBJ_WAIT
09:40Company: fun fact of the day: llvmpipe doesn't run out of descriptor pool memory, so my testcase doesn't break in CI
09:46jfalempe: sima: I'm looking into this error: https://lists.freedesktop.org/archives/dri-devel/2024-July/462635.html and it looks like I can't use the "atomic_t panic_cpu" if fbcon is compiled as a module. I didn't expect that :(
09:48sima: jfalempe, in other places we just looked at oops_in_progress to figure out whether the console printing is from panic context
09:49sima: not perfect, but at least in the past good enough
09:49sima: so maybe use that instead of your panic_cpu check?
09:50jfalempe: sima: ok, yes oops_in_progress is a function disguised, so that should work.
09:52sima: well we already use it all over the place in the drm fbdev code, so that one is available to modules for sure
09:55jfalempe: I'm just checking where this flag is set, but I will use that, thanks.
09:59jfalempe: sima: The only drawback is that we will lose the "not fatal" oops in fbcon if the drm driver supports drm_panic. But you can still retrieve it dmesg, because the system is still running.
10:00jfalempe: I will send a patch shortly to unblock the build.
11:21sima: jfalempe, yeah it's not perfect unfortunately
13:19zmike: eric_engestrom / dcbaker: maybe you have some idea on this: is it possible to have a static (internal) library which exports symbols for subsequent mesa linking but then have those symbols not exposed in the final .so link?
13:27zmike: cc daniels too
13:29MrCooper: definitely, IIRC this should be the default even, publicly visible symbols need to be marked explicitly
13:29zmike: right, but marking them publicly means they will be public in the final lib doesn't it?
13:29MrCooper: right, so don't do that
13:29zmike: but I need it visible for the intermediate link
13:30MrCooper: not making the symbol static should be enough for that
13:30zmike: apparently not
13:30MrCooper: k, then somebody else will need to take over I'm afraid
13:31zmike: yeah that's about where I'm at :/
13:33Company: zmike: that's enough pretty much
13:33Company: GTK builds GDK as a static library and then pokes into its private API all over the place from GTK
13:34zmike: 🤔
13:35Company: not sure if meson needs any flags during the build, you'll have to ask an expert about that (ie not me - but maybe meson.build knows)
13:57zmike: if I declare the symbols as attribute(weak) in the header everything works, but that's a bit hacky
13:59Company: zmike: maybe it's https://mesonbuild.com/Reference-manual_functions.html#both_libraries_link_whole ?
14:00ishitatsuyuki: no, you can't, ELF symbols are global by nature
14:00ishitatsuyuki: visibility and / or linker scripts are more of extensions
14:00ishitatsuyuki: and they only apply to shared libraries
14:01ishitatsuyuki: renaming the symbols with a prefix might work if the code is fully vendored
14:03zmike: the symbols are from a static library in src/gallium/frontends/dri and the user is a shared library inside mesa
14:23ifreund: Can I synthetically trigger a GPU reset somehow in order to test the ability of my program to recover from it?
14:24ishitatsuyuki: zmike: do you just need the symbol to be not exported from the shared library? or does the symbols conflict with another definition within the same shared library?
14:25zmike: the former
14:25ishitatsuyuki: you can use hidden visibility, or linker script specifying a whitelist of symbols to export
14:25zmike: right now I'm declaring them with attribute(weak) as a temporary workaround
14:25zmike: hidden doesn't seem to work
14:25zmike: well, no change in visibility works
14:25zmike: I think because it's a static library
14:26ishitatsuyuki: hidden should work, static library is just bundle of .o files
14:26zmike: well
14:26ishitatsuyuki: if you readelf -Ws file_from_static_lib.o does it show STV_HIDDEN?
14:28zmike: 681: 0000000000000000 32 FUNC GLOBAL HIDDEN 349 driGetAPIMask
14:29ishitatsuyuki: looks fine
14:29zmike: doesn't link though
14:29zmike: error: undefined symbol: src/glx/libglx.a(src/glx/libglx.a.p/dri3_glx.c.o): driGetAPIMask
14:29sima: jfalempe, in general for anything beyond cosmetic commit message edits it's best to resend
14:30sima: you can include all the r-b/a-b tags you've gathered so there's no wasted review
14:31Company: ifreund: iirc there's some debugfs file that does that?
14:31Company: but that's all I remember
14:32zmike: ishitatsuyuki: any other ideas?
14:32ifreund: Company: I tried echo 1 > /sys/class/drm/card0/device/reset as root but that didn't work (got "write error on stdout")
14:32ishitatsuyuki: zmike: where is driGetAPIMask defined in?
14:32Company: ifreund: did you try reding?
14:32zmike: src/gallium/frontends/dri/dri_util.c
14:32ifreund: I haven't found another /sys/ file that looks like it might do what I want yet
14:33ifreund: Company: no, but the permissions only allow writing by root
14:33ishitatsuyuki: zmike: that function is static, is it non-static in your local tree?
14:33DavidHeidelberg: karolherbst: heya, just run the CI job for freedreno and without code modifications, I noticed some improvements, but also char/uchar regression: https://gitlab.freedesktop.org/dh/mesa/-/jobs/61348164/artifacts/file/results/failures.csv
14:34zmike: right
14:35ishitatsuyuki: lemme recall static library linking rule again
14:37karolherbst: DavidHeidelberg: "UnexpectedImprovement(Fail)"?
14:37karolherbst: sure that those passed before?
14:37karolherbst: maybe there are still fails, but some sub-tests are now passing?
14:37ishitatsuyuki: zmike, is my understanding right that libfinal_product.so links libglx.a and libdri.a?
14:37DavidHeidelberg: not improvements, that's good, the "Fail"
14:38karolherbst: ahh
14:38DavidHeidelberg: karolherbst: UI(Fail) means it was crashing before
14:38karolherbst: ahh
14:38zmike: ishitatsuyuki: no, libglx is the final product that links libgallium_dri
14:38DavidHeidelberg: so it got a bit better, but other tests went from Pass -> Fail
14:38karolherbst: I see
14:38karolherbst: might need to bisect it if it's a stable fail
14:39zmike: ishitatsuyuki: err actually libgallium_dri is a .so
14:39zmike: so probably this is the issue
14:39DavidHeidelberg: it's I had two runs, sadly my clear_buffer MR brings one more fail, which I need to figure out
14:39karolherbst: DavidHeidelberg: I suspect some changes in the compiler
14:39zmike: because it's a .a -> .so -> .so
14:39zmike: not .a -> .so directly
14:39ishitatsuyuki: right
14:39zmike: so I think there's no solution here until I flatten it
14:40DavidHeidelberg: karolherbst: I'm just reporting now, I came to the Korea today, -x hours of sleep, so my best effort is now to tell :P I'll try to finish the clear_buffers so it can get in sooner and gets proper testing....
14:40ishitatsuyuki: yes, if you export glx symbols from libgallium_dri it will be available to every module in the process
14:41zmike: yeah
14:41zmike: so I'm just gonna keep doing a hacky workaround for now
14:42ishitatsuyuki: feel free to ping / ask on MR if you need a better solution for upstreaming
14:43zmike: I think (hope) it'll be okay since I'm gonna keep hacking away at it until it gets to a non-hacky final state before the next release
14:43zmike: but yeah, thanks
16:24gfxstrand: eric_engestrom, dcbaker: Any further thoughts on getting !30275 to build? Updating to meson 1.4.2 did nothing and it builds fine with clang locally
16:25dcbaker: gfxstrand: I was looking at it.
16:25gfxstrand: cool
16:27dcbaker: Here's what I'm thinking: clang doesn't like -pthread in the link line in a bunch of cases, it considers that dead code (Meson runs into this on macOS especially), so I'm thinking that debian has a bad combination of turning this flag on, and one of their dependencies putting -pthread in it's cflags (probably zlib or zstd, based on the command line)
16:30dcbaker: I'm wondering if we just want to set -Wno-... on that argument and move on. Because I can't reproduce locally either
16:30gfxstrand: I can certainly try
16:30gfxstrand: And the thing is, it does depend on something that uses pthreads
16:31gfxstrand: Just the rust code doesn't need it (kinda)
16:38dcbaker: Yeah, it might be worth my time to see if Meson can just filter -pthread from rustc link args...
16:39dcbaker: I forsee this being an ongoing issue...
16:39gfxstrand: dcbaker: While you're filtering Rust things, I ran into an issue with using idep_mesautil where it somehow ended up with some sources in it (from perfetto, maybe?) Those made rust choke.
16:40gfxstrand: IDK that just filtering sources is necessarily the right call but it's a pretty nasty corner to hit especially if those sources come from a wrap
16:41dcbaker: I think we can fix that without Meson changes
16:41gfxstrand: yes
16:43dcbaker: You should be able to do idep_mesautil.partial_dependency(compile_args : true, includes : true, link_args : true, links : true), to drop any sources that are included in idep_mesautil.
16:43dcbaker: But that will also drop headers....
16:44dcbaker: Might need Meson patches still
16:44dcbaker: sigh
16:44dcbaker: Never let anyone tell you build systems aren't hard, lol
17:05jimc: help diagnose job #61356474 ? python-test falls over with:
17:05jimc: 00:07
17:05jimc: $ cd bin/ci
17:05jimc: [01:06] ERROR: unknown-section: ret code: 1
17:22gfxstrand: dcbaker: Oh, that should work. I don't need includes in Rust. I just need them in the bindgen call
17:23dcbaker: gfxstrand: just be aware that there is a long standing bug that external dependencies mix includes and compile_args into compile_args, so if you have anything found via a `dependency()` call, you need `compile_args : true` to get the includes
17:24dcbaker: I've written patches a few times for this, but never quite get it all working
17:37gfxstrand: dcbaker: Sweet! All I need are link_with and links so that works a treat
17:37dcbaker: yay!
17:40gfxstrand: dcbaker: If I'm going to add -Wnounused-command-line-arguments, where should I do that?
17:40gfxstrand: In rust_args?
17:41dcbaker: That's where I'd start. If that doesn't work then link_arguments
18:16gfxstrand: dcbaker: I put it in link_args and it's still failing
18:17gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61361730
18:17gfxstrand: looking at it locally, I don't see that making its way into my build.ninja at all
18:18dcbaker: gfxstrand :( This sounds like a problem for after lunch. I'll have a look then and see what I can come up with
18:28gfxstrand: dcbaker: You may also have opinions about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30277
18:33gfxstrand: dcbaker: Looks like I've got it. -Clink-arg=-Wno-unused-command-line-arguments
18:33dcbaker: gfxstrand: since we went to symlinks that make sense to me.
18:33dcbaker: gfxstrand: that makes me think we're not handling `link_arguments` in rust targets...
18:35gfxstrand: dcbaker: Yeah, putting it in link_args did nothing
18:36gfxstrand: Unless link_arguments and link_args are different (but that would be nutty)
18:36dcbaker: no, it's probably called link_args and I'm writing the wrong thing
18:36dcbaker: too many plates in the air, each with their own opinion on what we should abbreviate, lol
18:37dcbaker: I would not be surprised if rust targets ignore link args, I'll have to look at that
18:37gfxstrand: Yup
18:41karolherbst: DavidHeidelberg: oh btw, please tell me once you are officially ready to drop clover support, because then I'm gonna clean up quite a lot
19:49Lyude: Does anyone know whether or not /all/ KMS drivers capable of performing non-blocking modesets would be using drm_atomic_helper_wait_for_flip_done()? Or are there usecases for such a driver possibly using drm_atomic_helper_wait_for_vblanks()?
21:30Sachiel: gfxstrand: opinion on how to handle VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT in mesa? It's a trivial if in vtn, but we'd have to pass the flag to vk_pipeline_hash_shader_stage(). Or we can keep not passing pipeline creation flags in there and have a pass after that does s/ViewIndex/DeviceIndex/ that every driver has to call