00:02 cmarcelo: dcbaker: ah, that makes sense. thanks.
00:13 tarceri_: mareko: I'm working on moving it over but it's a tricky one
10:27 tzimmermann: mripard, i pinged patrik about the gma500 repo
10:36 zzag: idr: here's complete backtrace with debug symbols: https://invent.kde.org/-/snippets/2842
10:36 zzag: should I file a bug report?
10:40 donaldrobson: Hello all. I'm quite new to this, so please forgive the question if it should be obvious. Should there be a 1:1 relationship between vulkan semaphores and drm_syncobj?
10:43 ishitatsuyuki: probably, not sure what are you asking for though
10:44 ishitatsuyuki: you probably want to start digging from here https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/runtime/vk_semaphore.h
10:44 ishitatsuyuki: vk_semaphore should back the VkSemaphore if the driver uses the common impl
10:51 donaldrobson: I'm trying to debug test failures we have with dEQP-VK.synchronization.op.multi_queue.binary_semaphore tests where it seems the kernel isn't waiting for the write to finish before submitting the read. I put extra traces in the kernel to track the drm_syncobj that go with the signals and waits, but they have different addresses. I'm wondering is this means that the read is actually waiting for a different semaphore than is signalled by the write
10:54 tjaalton: dcbaker: why is staging/23.2 rewriting history, it's missing half of rc3?
11:09 mripard: tzimmermann: thanks ):
11:09 mripard: * :)
12:42 karolherbst: austriancoder: fyi: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25330
12:42 karolherbst: I decided that backends have to do it, but the new pass will clean up some remaining stuff
12:43 austriancoder: karolherbst: thanks .. will give it a try
12:44 karolherbst: I think it's the same code you tested already as I don't think I've changed it, I just moved from rusticl into zink. But yeah... you might have to write your own callback or improve what you already have
13:55 dcbaker: tjaalton: bisecting regressions I cannot reproduce locally
13:56 dcbaker: Which are caused by multiple commits, so once I figure out which commits to remove I’ll put it all back and revert those commits
14:00 tjaalton: okay
14:20 pq: Fun fact: there are two different "full range" quantizations, in addition to limited range. https://tech.ebu.ch/docs/r/r103.pdf
14:28 zamundaaa[m]: pq: that doesn't sound fun
14:30 pq: I suspect the other one is mostly found only in real-time TV production/broadcasting equipment, though I have some vague recollection that JPEG was supposed to use it but no-one actually did
14:31 pq: would be nice to see what HDMI and DP use, but I'm not *that* bored :-)
17:23 karolherbst: dcbaker: what can I do to fix the "old bindgen" CI fails of https://github.com/mesonbuild/meson/pull/12263?
17:23 karolherbst: but also that mypy lint error is something I should address I guess https://github.com/mesonbuild/meson/actions/runs/6251685170/job/16973338401?pr=12263
17:23 karolherbst: any suggestions for both?
17:28 dcbaker: karolherbst: we need to rebuild the CI images, I haven't done that in a while, let me check with Eli who's done it more recently
17:28 karolherbst: okay, cool
17:51 karolherbst: dcbaker: and any ideas what I can use instead of `version_compare`?
18:10 anholt: DavidHeidelberg[m]: I'm concerned about the ci-deb-repo plan -- so on every merge to main of that repo, every package gets rebuilt and a new copy of it uploaded into LFS forever? Even if that package wasn't modified by that MR?
18:57 dcbaker: karolherbst: hmmm, it's a really annoying problem. You might for now just assume that if `bindgen` is an Executable it's of an appropriate version, but with a TODO comment
18:57 dcbaker: it isn't actually possible to hit that path ATM, because that would require rust subprojects
18:58 karolherbst: couldn't Executable also get a get_version function instead though?
18:58 karolherbst: ehh
18:58 karolherbst: I guess it's not compiled at that point if it's coming from a subproject :'(
18:59 dcbaker: Yes, it should. It's just non-trivial to plumb trhough
18:59 dcbaker: we do this already for dependencies
18:59 dcbaker: but we need to do it for exectuables as well
18:59 karolherbst: ahh
19:00 dcbaker: But currently it isn't possible for it to actually happen, so we could just ignore it it, and I'd be okay with that. I'd even be fine with an assertion and consider it something that needs to be fixed as part of the cargo subproject bringup
19:00 karolherbst: okay.. how would I check for the actual type in python?
19:07 dcbaker: if isinstance(exe, Executable): (or ExternalProgram), whatever makes more sense
19:20 karolherbst: dcbaker: do I have to do anything to make the linter happy on top of the isinstance check?
19:21 karolherbst: maybe I should just run the linter locally...
19:42 gfxstrand: alyssa: RE gl_LayerID, ugh...
19:43 gfxstrand: alyssa: I really hate that we have all these "is it a sysval?" flags.
19:43 gfxstrand: alyssa: nir_lower_sysvals_to_varyings is your friend, I think.
19:43 gfxstrand: alyssa: If we need to add more flags to it, we can do that.
19:50 DavidHeidelberg[m]: anholt: only if the package is changed. So every other packages remains as it was before, just deb indexes are updated
19:51 anholt: how is package change being detected? It looked like you're just stuffing all the new debs in the repo.
19:53 DavidHeidelberg[m]: anholt: by chamge of $package.yml
19:54 DavidHeidelberg[m]: If it'a not touched, package build is skipped and existing .deb packages will be used
19:54 anholt: oh, you're enabling jobs conditionally, and using that to only change those debs. interesting.
20:35 alyssa: gfxstrand: that pass is the wrong direction, though
20:35 alyssa: both glsl and spirv produce varyings for layerid
20:36 alyssa: it's just vk meta which is producing different nir from vtn
20:38 alyssa: I think?
20:39 alyssa: ir3_nir_lower_layer_id does the sysval->varying lowering
20:39 alyssa: hm
20:40 alyssa: ..how is this supposed to work?
20:40 alyssa: both glsl and vtn produce a varying, I have no idea where the sysval comes in..
20:43 alyssa: FFS
20:43 alyssa: nvk_shader.c turns the sysval back into the varying!!
20:43 alyssa: this whole thing is a mess
20:43 alyssa: gfxstrand: can we whack the sysval? who actually wants it?!
20:43 gfxstrand: Yes, it's a mess
20:44 gfxstrand: Intel wants it
20:44 gfxstrand: I'd really rather whack the varying
20:44 alyssa: Why?
20:44 gfxstrand: For things like meta, it's SO much easier to just do nir_load_foo
20:45 alyssa: We can add helpers for that
20:45 alyssa: But it's logically a varying
20:45 gfxstrand: Yeah.... IDK.
20:45 gfxstrand: By what logic?
20:45 alyssa: VS writes a value and the FS reads whatever the VS wrote
20:45 gfxstrand: Yeah...
20:45 alyssa: If you treat it as a varying you'll get the write behaviour
20:46 gfxstrand: The fact that it's also an output makes that one a bit different...
20:46 gfxstrand: IDK
20:46 alyssa: (and Intel could do that, it's just less efficient)
20:46 gfxstrand: I hate builtins in general. :-P
20:46 alyssa: The fact that everyone BUT intel wants it as a varying is telling
20:47 simon-perretta-img: (We also want/would prefer it as a sysval heh)
20:47 alyssa: and both nvk and ir3 have different code to produce varyings of the sysval due to common code being inconsistent
20:47 alyssa: simon-perretta-img: >:)
20:48 Kayden: hang on
20:48 gfxstrand: So, Intel actually has two things (which is probably why Kayden is confused)
20:48 Kayden: gfxstrand, alyssa: Sachiel and zmike recently worked with Piers to get the spec for layer-id/viewport-index changed
20:48 alyssa: at any rate I don't think vk_meta necessarily needs a knob.. but something is inconsistent here
20:48 Kayden: It's now undefined to pass out of bounds values from one stage to the next
20:48 Kayden: and the piglit tests are going away
20:49 Kayden: I believe Sachiel is deleting our code to use generic varyings and we can just read the payload fields as a system value
20:49 gfxstrand: Cool
20:49 gfxstrand: Because it's a system value. :)
20:49 gfxstrand: hehe
20:49 Sachiel: I'll get back to that after I come back from vacations
20:49 Kayden: I don't think we've gotten there yet but yeah I think that's where we want to go, and we can probably make the varying go away with a bit of tidying.
20:51 Kayden: it is definitely weird that it has the dual behavior :/
20:53 gfxstrand: Broadly speaking, though, this is one of those areas where I'd weight consistency in NIR over drivers having to do a tiny translation, precisely to avoid these issues..
20:53 gfxstrand: Like the translation I'm doing in NAK costs me virtually nothing from a code maintenance PoV.
21:24 jessica_24: hey koike, abhinav__ and I have been working on adding a new Gitlab runner to the drm/msm CI (https://gitlab.freedesktop.org/drm/msm/-/merge_requests/76). However, we've been facing a yaml parse issue after upreving the mesa commit sha. It seems to be related to this commit
21:24 jessica_24: (https://gitlab.freedesktop.org/mesa/mesa/-/commit/8ee6e3d8d6413eb4636e4be60bbfab1b5bbb2eed) causing some dependency issues
21:25 jessica_24: do you have any ideas on how to resolve this (hopefully without having to add a lot of extra dependencies to drm/ci/gitlab-ci.yml)?
21:26 zmike: the piglit tests are already deleted
21:26 jessica_24: this part of an ongoing discussion on #freedreno, so feel free to join there too
22:42 alyssa: gfxstrand: sure. I don't care whivh way we g
22:42 alyssa: go
22:42 alyssa: but right now varyings are somehow canonical and the sysvals are driver-translated
22:42 alyssa: seems less work to go that route to make things consisyent
22:45 gfxstrand: Except there's nothing "canonical" about gl_Layer. It's a built-in. It's magic.
22:45 gfxstrand: IDK what you even mean by "varyings are somehow canonical". What's a varying and what's a sysval is a giant tangle.
22:46 gfxstrand: Built-ins that end up as outputs somewhere typically have a VARYING_SLOT. That's about all the canonicalizaiton there is
22:47 gfxstrand: But inside a fragment shader, many of those (including gl_Layer) are very much not varyings, depending on hardware.
22:48 gfxstrand: Any more than gl_Position and gl_FragCoord are the same
22:51 gfxstrand: The fact that there are dozens of nir_intrinsic_load_foo which don't have a SYSTEM_VALUE_FOO enum and therefore don't get recorded in system_values_read is, admittedly, quite problematic.
22:52 alyssa: fair enough
22:53 alyssa: I don't really care how the tangle is resolved. I just have a nagging feeling Ill end up being the one detangling :v
23:07 gfxstrand: lol
23:20 dcbaker: zmike: I'm giving up. I've tried to bisect the zink-lvp job. I've come up with two commits that seem to cause a massive number of regressions, I've reverted them both. I'm still seeing huge numbers of fails on the job. Would you be able to help? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49306532
23:21 zmike: sure
23:21 zmike: I'll look first thing tomorrow
23:21 dcbaker: thanks
23:21 zmike: whoa that is huge numbers
23:27 zmike: dcbaker: do you have any completed pipelines for this?
23:27 zmike: and/or have you looked at any of the test logs to see if there's anything useful
23:28 dcbaker: I looked at the logs when I startedand I think it was an assert of some kind, of course the rebase lost all of the pipelines :(
23:32 zmike: and obviously it would be too easy if I could repro any of this locally...
23:37 zmike: found one https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49301962
23:38 zmike: except it refuses to load any of the artifacts
23:38 zmike: incredible
23:39 zmike: ohhhhhhhhhhhhhhhhhhhhh
23:41 zmike: dcbaker: good news bad news
23:41 zmike: good news is I think this is extremely simple to fix
23:41 zmike: bad news is this has implications for future stable branch things
23:42 dcbaker: zmike: oh boy :)
23:51 zmike: still time to cut the release today!