05:17 mupuf: alyssa: sounds likely! The usual fix is a drirc entry
05:18 mupuf: Apitrace reports itself as the binary it traced, so options will be applied automatically
05:47 mupuf: That being said, if zero init has a low overhead, it may be a good idea
07:53 karolherbst: anholt_: anyawy.. seems like one of the missing things in v3d is vectored non 32 bit load/stores. Any idea on how to wire that up? Didn't look to much into the compiler beyond just making load/store global work
15:32 karolherbst: mupuf: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44367508 not sure what's up, but is the system really busy or the machines being broken?
15:33 mupuf: karolherbst: shit, again!
15:34 mupuf: Should fix itself
15:34 mupuf: I'll have a look in 10 minutes, when I come jomw
15:34 mupuf: Home*
15:34 karolherbst: cool, thanks
15:35 mupuf: Wait, I think I get it :D
15:35 mupuf: Quick fix to dxvk ci should fix it
15:59 mupuf: karolherbst: should be fixed! Thanks for reporting the issue
15:59 karolherbst: mupuf: do I have to restart the job? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44371321
16:00 karolherbst: or will it just pick something up on its own?
16:00 mupuf: karolherbst: I just freed the runner, it should start on its own now
16:01 karolherbst: yeah, it did :)
16:01 mupuf: so sorry about that!
16:07 mupuf: well, at least, the pipeline was fixed before it even expired, so... yeah us?
16:07 mupuf: FYI, the issue is that mesa CI has a 1:1 association between the gitlab runner name and the runner in my farm... but dxvk-ci did not have this just yet
16:07 karolherbst: ohh, there are already two timeouts on that MR :P
16:07 mupuf: oh, so sorry :s
16:08 karolherbst: don't worry, there was also a bug....
16:08 karolherbst: I think marge should be improved here a little
16:08 karolherbst: saying it timed out is nice, but it might help with marge also reports that there were failed jobs as well
16:09 mupuf: oh, right, would be nice too
16:09 mupuf: and it would be nice for marge to say which jobs were still active
16:09 mupuf: anyway, back to weekend!
16:54 daniels: yeah, that’s on the list of things to improve
17:41 LaserEyess: I'm trying to debug this bug https://gitlab.freedesktop.org/mesa/mesa/-/issues/9210
17:42 LaserEyess: if I just want to bisect the libva driver, what target do I need to compile?
17:42 LaserEyess: meson compile -C build $what
17:42 LaserEyess: I'm just going to do LIBVA_DRIVER_PATH (or whatever the env is) to test this
17:47 LaserEyess: my best guess is `gallium_drv_video` and `radeonsi`
18:36 DavidHeidelberg[m]: LaserEyess: just compile whole mesa, you'll get stuff cached anyway 😉 (I guess I'm replying too late anyway)
18:37 LaserEyess: you are too late but don't worry that's what I ended up doing
18:47 psykose: bisect keeps the builddir so all you're paying is the meson reconfigure and then a few objects+link
18:47 psykose: it's pretty reliable most of the time
19:06 LaserEyess: alright, so
19:06 LaserEyess: with arch's package https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/blob/main/PKGBUILD, I get a GPU reset
19:07 LaserEyess: compiling from source I get an assertion failure
19:08 LaserEyess: https://gitlab.freedesktop.org/mesa/mesa/-/blob/22.3/src/gallium/auxiliary/util/u_handle_table.c#L226
19:09 LaserEyess: oh whoops, wrong branch, but same line in main
19:11 LaserEyess: I'm just doing `-Dgallium-drivers=radeonsi,swrast -Dgallium-vdpau=disabled -Dgallium-va=enabled -Dvideo-codecs=h264dec`
19:11 LaserEyess: I guess I'll copy arch's options and see what happens
19:12 bluetail: LaserEyess on i3 or wayland
19:12 LaserEyess: tty
19:12 bluetail: thats interesting
19:12 LaserEyess: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9210#note_1973854
19:12 LaserEyess: this command
19:12 bluetail: I've recently been doing my mkinitcpio -P run and it resetted the gpu as well
19:12 bluetail: there must be something broken
19:13 bluetail: also on 6950xt
19:13 LaserEyess: this is specifically for the reproduction steps in #9210
19:13 LaserEyess: I'm not getting random resets
19:14 kurufu: I believe you need `-D b_ndebug=true` to disable asserts.
19:14 bluetail: I want to reproduce
19:14 LaserEyess: kurufu: ohh, that must be what I'm missing then
19:14 llyyr: yeah I build with -Db_ndebug=true and get gpu reset instead of assertion failure
19:15 bluetail: -f: No such file or directory
19:15 bluetail: do I need to put an actual file?
19:15 LaserEyess: ok, so, actually I discovered the bug
19:15 LaserEyess: bluetail: yes
19:15 LaserEyess: sub $video with the video in the OP
19:17 bluetail: I do something wrong... "Device setup failed for decoder on input stream #0:0 : Input/output error"
19:17 bluetail: I'll try a demo file...
19:20 bluetail: LaserEyess I need corrupted video for it right? Cause it didnt crash with OP's mpv command. But that one at least worked out for me
19:20 bluetail: I use a 6950xt
19:20 bluetail: I'm on i3
19:21 bluetail: I try your video now...
19:21 LaserEyess: you have to use that specific video, yes
19:21 LaserEyess: it only seems to happen for corrupted h264
19:22 bluetail: No I dont crash in mpv
19:22 llyyr: that's weird, i also get a crash on 6600 xt with that video
19:22 bluetail: using the mpv command?
19:23 bluetail: or the ffmpeg one?
19:23 llyyr: mpv just uses ffmpeg, it crashes with both when decoding with vaapi
19:23 bluetail: it works fine for me. what mpv version and version of mesa are we using. lets compare!
19:24 llyyr: mesa master, and the original reporter used 23.1.2
19:25 bluetail: glxinfo -B returned this: http://ix.io/4z0q
19:26 bluetail: this is my mpv ver http://ix.io/4z0p
19:26 bluetail: I can provide an actual mpv log
19:27 bluetail: heres the mpv log http://ix.io/4z0t
19:29 llyyr: well that's because your hwdec is broken
19:29 llyyr: mpv tries to use vaapi but fails
19:29 llyyr: fix your system i guess
19:29 bluetail: wdym broken?
19:30 llyyr: it's not using vaapi [ 0.063][v][vd] Using software decoding.
19:30 bluetail: oh
19:30 llyyr: [ 0.044][d][vo/gpu/vaapi/vaapi] libva: va_openDriver() returns -1
19:30 bluetail: how do I get vaapi?
19:30 bluetail: do I reinstall mesa?
19:31 llyyr: install vaapi drivers, that's libva-mesa-driver on arch idk what distro you're on
19:32 bluetail: oh I'm on arch
19:34 bluetail: llyyr ok crashed now :D
19:35 bluetail: I'll comment it
19:40 LaserEyess: is there a way to force a specific llvm version?
20:03 LaserEyess: starting to really doubt I understand this bug because I'm way back at 21.3-branchpoint
20:06 llyyr: are you sure it's a regression?
20:06 LaserEyess: in mesa? not particularly, but it's reproducible in 5.19
20:06 LaserEyess: firmware bug? idk
20:07 LaserEyess: I hit that assertion failure so that's clearly some sort of bug
20:17 LaserEyess: git checkout 22.2 <-- GOOD
20:21 DavidHeidelberg[m]: bluetail: https://github.com/intel/libva-utils
20:22 DavidHeidelberg[m]: it has whole test-suite which you can use to bisect I guess
20:22 bluetail: DavidHeidelberg[m] I think you either tagged the wrong person or you are a bit late to the talk
20:23 bluetail: We did reproduce the issue of LaserEyess
20:23 DavidHeidelberg[m]: oh cool! I just saw the message and didn't follow discussion, I see now :P
20:25 LaserEyess: no that's a lie, damn it
20:26 LaserEyess: I went far enough back to remove -Dvideo-codecs=h264dec
20:27 llyyr: I think it's probably always been broken...
20:28 llyyr: for files like that at least, ffmpeg complains about the same frame containing a reference and a non-reference field
20:30 LaserEyess: well even if it's always been broken (which I'm double checking by removing assertions) it shouldn't be hitting that assert in mesa, and it shouldn't be doing a gpu reset
20:32 LaserEyess: could asan help here?
20:33 bluetail: that kinda reminds me of that 'unsolvable' gpu reset in wayland that only I had... sorry for the noise
21:02 LaserEyess: is this anything???? https://gitlab.freedesktop.org/mesa/mesa/-/issues/9210
21:02 LaserEyess: I'm flailing here