04:00 airlied: anholt_: gk20a seems to be failing to find artifacts
04:00 airlied: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/42243524
05:10 DavidHeidelberg[m]: airlied: anholt the proxy is down (at least seems to be)
05:18 kode54: should I just post that Xe uAPI patch series I made?
05:18 kode54: mlankhorst seems to be quite busy with something
05:18 kode54: then again, I assume most of the @*.intel.com people are employed and probably have NDA things they have to do during work hours
05:19 kode54: unless Intel also employs people to work full time on their FOSS stack
05:21 kode54: I have to wait for mbrost's newest patch series to be applied for one half of my patch set to apply anyway
05:22 kode54: which is part of why I wanted to accelerate revising it a bit
06:18 DavidHeidelberg[m]: just to be sure, any additional review on AVX512 detection code adjustment? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23164/
06:19 DavidHeidelberg[m]: much small, very easy to review, removes a GCC warning, such wow.
08:56 Shibe: Hi, maybe not the best place to ask this, but is Mesa 23.1 actually out? I know Phoronix announced it but the mesa website still displays 23.0 as the latest version and it's not in fedora or flatpak yet either
09:28 kode54: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/42255702 this looks like a crashed machine
09:33 ishitatsuyuki: you might want to cross post/check in #freedesktop
09:48 kode54: thanks
10:05 shadeslayer: daniels: is there a way for me to bisect https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20153 on a630?
10:27 daniels: shadeslayer: no automatic way no, you'd just have to send one branch per commit and use ci_run_n_monitor --target a630-traces
10:33 kode54: holy crap
10:33 kode54: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/42075886/artifacts/results/summary/results/trace@freedreno-a630@supertuxkart@supertuxkart-mansion-egl-gles-v2.trace.html
10:33 kode54: the difference is some pixels on the second car from the left, differing by 1-2 in value from the reference
10:35 kode54: ah
10:35 kode54: it's more than 1-2 level difference
10:35 kode54: reference image makes the car and tires all black
10:36 kode54: rendered image actually lights what looks like a car
11:01 daniels: kode54: if it makes things better, update the checksum in the traces YAML file to the new image's checksum
11:02 kode54: I'm not sure if this is specific to the tree that was failing CI, or if it was just a flake
11:02 kode54: also not my MR that failed
11:03 kode54: if it were my MR, and it was causing this one platform to render differently, I'd add the hash change to the MR
11:03 kode54: I can probably notify the MR comment stream though, if they don't already know
11:23 shadeslayer: kode54: is that on main? because I'm seeing it on my MR
11:26 shadeslayer: kode54: ah yes, that's my MR :)
11:37 shadeslayer: I'm gonna retry it, because entirely possible it's a flake
11:49 eric_engestrom: airlied, DavidHeidelberg[m]: I've disabled anholt_'s farm for now (on her suggestion); you can re-assign the MRs that failed because of that
11:51 eric_engestrom: Shibe: it's out, I just forgot to update the website 🙈
11:51 eric_engestrom: doing that now
11:54 shadeslayer: daniels: kode54 yeah looks like a flake, since it passed on a retry
11:56 daniels: right, but is it an existing or new flake ...
12:02 shadeslayer: daniels: can I get rights to run CI on my mesa repos? so that I can bisect the failure
12:02 shadeslayer: https://gitlab.freedesktop.org/shadeslayer/mesa
12:06 daniels: shadeslayer: oh yeah sure, done
12:06 shadeslayer: daniels: thank you!
12:19 DavidHeidelberg[m]: eric_engestrom: thanks!
13:13 shadeslayer: daniels: ci_run_n_monitor.py should trigger parent jobs right?
13:13 daniels: shadeslayer: it does, yeah
13:15 shadeslayer: daniels: hm, barfs here https://gist.github.com/shadeslayer/aa5827e6eeac603d4da00cf418272713
13:15 daniels: shadeslayer: it can't connect to https://gitlab.freedesktop.org - at a guess that's because Intel makes you go through a proxy
13:16 shadeslayer: yeah they do -.-
13:16 daniels: https://docs.aiohttp.org/en/stable/client_advanced.html?highlight=proxy#proxy-support
13:19 shadeslayer: thanks again, I'll just connect directly for now
13:19 daniels: shadeslayer: if you edit .gitlab-ci/bin/gitlab_gql.py and add client_session_args = { "trust_env": True } to the self._transport = AIOHTTPTransport(...) args, does that work?
13:24 shadeslayer: daniels: yeah, seems to work
13:25 daniels: nice :)
13:25 daniels: congrats for being the person from Intel to try that tool then, I guess
13:25 shadeslayer: hahah
13:55 zmike: what's that env var to disable the vk wsi thread?
14:01 MrCooper: git grep can't seem to find any
14:02 zmike: yeah that's my issue
14:02 zmike: maybe I hallucinated it
14:02 alyssa: zmike is an LLM confirmed
14:06 ccr: now just to find working glitch tokens ..
14:29 robclark: mareko, zmike: any opinion about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23149/diffs?commit_id=25a6875ce80daddeb0ad62e0b1988ac3939cf828
14:29 zmike: huh
14:30 zmike: seems good
14:31 robclark: yeah.. seemed like a simple trick to cut out a good chunk of overhead when clamp not needed
14:33 robclark: btw zmike, I'm not entirely sure why zink doesn't need to lower clamp.. you don't seem to handle PIPE_TEX_WRAP_CLAMP
14:33 zmike: ?
14:33 robclark: PIPE_CAP_GL_CLAMP or something along those lines
14:33 zmike: not needing clamp in zink sounds like fake news
14:33 zmike: I wrote clamp emulation for zink
14:35 robclark: iirc, PIPE_TEX_WRAP_CLAMP was the one case I need to emulate.. but that enum seemed to be ignored in zink when I looked a week or two back.. maybe I was overlooking something
14:35 alyssa: robclark: PIPE_CAP_GL_CLAMP means a driver *supports* clamp
14:35 alyssa: The u_default value is 1, meaning unless overriden a driver supports clamp
14:36 alyssa: If a driver does not support clamp, they need `case PIPE_CAP_GL_CLAMP: return 0` to indicate they do NOT have the capability of gl_clamp'ing
14:36 alyssa: ...which Zink does
14:36 alyssa: In other words, the CAP is about what the driver supports, not what lowerings the frontend should do as a result
14:36 robclark: hmm, when I looked I thought zink was returning 1
14:37 robclark: hmm, I guess not
14:45 alyssa: :+1:
15:10 alyssa: karolherbst: does your thumbs-up mean you'll write the nouveau patch? :-P
15:11 karolherbst: it means a thumbs-up
15:11 karolherbst: but maybe
15:11 karolherbst: those barrier intrinsic scare me
15:11 alyssa: how so?
15:11 karolherbst: no idea
15:12 alyssa:writes the Zink patch
16:14 karolherbst: gfxstrand: any opinions on how we want to deal with rustc version bumps? I wanted to land a bugfix, but it crashes the compiler on 1.59. We might want to settle with some rules, like max is debian next or whatever
16:15 karolherbst: no idea what you depend on in NAK atm
16:27 alyssa: zmike: cheating off vtn for my ntv patch
16:27 alyssa: am i doing it right
16:27 zmike: yup
16:27 zmike: bonus points if you copy glslang too
16:34 alyssa: :-D
17:51 tpalli: nouveau ci has some problems, proxy is not setup correctly (?)
17:52 tpalli: marge refuses to merge because that is failing
18:26 eric_engestrom: tpalli: fixed in 520c5091d7de4290f87b (by disabling that farm), it will work next time you assign to marge :)
18:55 tpalli: eric_engestrom thanks!
22:45 jenatali: O.o the constant expression for nir_unpack_64_4x16 is wrong...
22:54 jenatali: And has been for 5 years
22:58 bifidock: Hi, I have a weird performance problem running some games and I want to debug it but I have no experience with that. I'd like to ask someone who can help me with that. Is it the right place?