00:52clee: HdkR: I figured why not start with the one arch I can actually verify it on
00:53HdkR: :)
05:31tjaalton: gfxstrand: i have the mangling done locally, and got some help via #debian-devel to fix the rest, but testing will have to wait for until I'm back home
05:32tjaalton: nvk will be enabled where llvm or rusticl is enabled
05:33tjaalton: i just hope meson/rust will be more stable at some point, because backporting mesa is a pita now
07:39tzimmermann: mripard, makes sense, but wasn't there such a template already?
07:40mripard: tzimmermann: there was one in freedesktop/freedesktop: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/blob/master/.gitlab/issue_templates/New%20SSH%20account.md?ref_type=heads
07:41mripard: but that was to create a cgit account, so most info are kind of moot now
07:41tzimmermann: ok, i see.
07:41mripard: it's still what we document people to use though, so it's kind of weird
07:41mripard: like, we still require a GPG key, but don't use a GPG key anymore
07:42tzimmermann: all new accounts are set up via gitlab, right?
07:43tzimmermann: or at least commit permissions are adjusted (?)
07:48mripard: yes, both accounts and permissions are done through gitlab now
07:48mripard: which is kind of why it's weird: we don't require a cgit account at all anymore
09:13mripard: tzimmermann: so, should I push it and send a doc patches?
09:13tzimmermann: mripard, i'm ok with it. but maybe others have comments
09:15tzimmermann: ^ mlankhorst, daniels
10:41karolherbst: who wants to review a gallivm patch adding nir_lower_mem_access_bit_sizes? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29896/diffs?commit_id=5ff160b2921d1adafa4490dc9312d6bb02765e28
10:41karolherbst: I'd kinda like to merge this MR as it fixes some issues with vtn (OpenCL only tho)
10:49gio: alyssa: I just watched your XDC2023 presentation. You say that you implement geometry shaders by first running a stripped down version of the geometry pipeline to count how many slots the geometry shader is going to use. But what happens if some shader writes to device memory? Either you drop the write, but then the pipeline might behave differently than it should, or you don't,
10:49gio: and then you've altered the global state and the real run might do something different.
11:27tzimmermann: jfalempe, there's a copyright notice in the middle of drm_panic.h
12:54jfalempe: tzimmermann: yes I think it's when I merged the panic locking patch https://lists.freedesktop.org/archives/dri-devel/2024-March/444225.html
12:55jfalempe: I will add this to my drm_panic cleanup series.
13:17alyssa: gio: yeehaw
13:20gio: I'm not sure of what that means...
13:24graphitemaster: What hoops would I have to jump through to enable full subgroup ops in RadeonSI? I noticed that RADV has this special case where if the shader uses a wide subgroup intrinsic and the local size is a multiple of 64, it will force itself to use wave64 instead of wave32 as can be seen here https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_shader_info.c#L970-976 the RadeonSI approach doesn't do anything similar
13:24graphitemaster: in si_determine_wave_size here https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_state_shaders.cpp#L29 and it would be pretty handy if it did.
13:28alyssa: gio: APIs explicitly allow the GS to be invoked multiple times
13:29alyssa: if the GS behaviour depends on side effects happening exactly once, that app is in for a bad time.
13:29alyssa: asahi has some simple heuristics to try to do something reasonable with GS side effects (and the current approach passes both GL and VK CTS fwiw)
13:30alyssa: you can certainly construct an evil GS that would fail that. and, I would argue, that GS depends on behaviour that the spec explicitly does not guarantee.
13:32karolherbst: I always forget about this cursed restriction of the spec
13:32karolherbst: I actually wonder which hardware required it when the spec was drafted
13:33alyssa: I think all tilers have something like this
13:33alyssa: qualcomm definitely executes GS multiple times
13:34alyssa: as does broadcom iirdc
13:34alyssa: arm doesn't have hw GS but presumably their sw emulation is similar to mine, since this is really the only way to handle things both correctly and efficiently in the presence of transform feedback
13:36karolherbst: mhhh.. actually, when the spec/extension was drafted, could a gs even cause side-effects?
13:36karolherbst: image load/store is newer than gs or not?
13:37karolherbst: ssbo maybe as well
13:37alyssa: dunno and I'm not interested in litigating this, thanks
13:37karolherbst: :D
13:37karolherbst: fair enough
13:40gio: Where is that written? In the spec I see an informative note about vertex shaders (https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap9.html#shaders-vertex-execution), but if there is anything about tessellation or geometry shaders I can't see it.
13:42gio: The most explicit thing I can find is saying that "A geometry shader is invoked at least once", maybe that's intended that way.
13:43gio: Maybe I was too boring, I can understand that...
16:13alih: Hi. Is there a simple(r) way to replicate a gitlab ci pipeline job locally? I'm trying to see if I can replicate an old failed job (zink-lvp) and/or resolve it by testing locally.
16:22alih: I guess the problem I think I'm running into is I'm not sure how the container was mounted. So while I can browse the logs and see what image was used, I am unsure what additional flags went into mounting it (volumes, env vars, et al)
16:33meltq: dianders: do the comments documenting each of the multi functions need to be preserved after converting the functions to be generated by macros?
17:07dianders: meltq: I wouldn't think so. I was somewhat thinking you might be able to add a macro and add the multi variant like:
17:07dianders: `MIPI_DSI_ADD_MULTI_VARIANT(mipi_dsi_turn_on_peripheral, "turn on peripheral")`
17:07dianders: ...and then you could just add that after the existing `EXPORT_SYMBOL`. I haven't prototyped that and we'd need buyin from others in the DRM community, but it seems plausible?
17:10dianders: meltq: One thing that I just noticed is that for most of the function we'd be wrapping the return value is normally an `int`, not a `ssize_t`. That's a (minor) bug in the recent multi functions where they temporarily store things in `ssize_t` for no good reason. Maybe we'd want to keep the "write buffer" and "dcs write" separate so we could keep the `ssize_t`for those and get everyone else using an int locally.
18:32alyssa: libEGL fatal: DRI driver not from this Mesa build ('24.2.0-devel (git-112e410dbe)' vs '24.2.0-devel (git-cc3ff426bb)')
18:32alyssa: ...Well, that's new since an hour ago (:
18:34alyssa: openat(AT_FDCWD, "/home/alyssa/mesa/build/src/egl/libEGL.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
18:35alyssa: a broken link. my that *is* exciting
18:35alyssa: corrupted build/ I guess?
18:35alyssa: entertaining =)
18:35alyssa: Yup. fs corruption. Entertaining indeed (:
20:03karolherbst: oof
20:03karolherbst: good luck
20:07DemiMarie: alyssa: hopefully you didn't lose any data
20:37alyssa: karolherbst: oh, I just torched the build/ and rebuilt and it went back to working, just ... a big clown emoji :)
20:37karolherbst: fun...
20:38karolherbst: years ago (like 8 or so?) I managed to crash my machine doing nouveau stuff, back at the time btrfs wasn't as stable, so trying to remove the corrupted directory caused a kernel panic :')
20:39alyssa: knice
20:39alyssa: once in a while, I'll write a patch so broken that trying to CTS it hangs the machine, and then the force reboot causes fs corruption such that I lose the patch and no longer have the patch in my .git
20:39alyssa: we call that self-healing
20:39karolherbst: funky
20:39alyssa: :P
20:40alyssa: (this definitely happened on the ext4 debians, not sure if I've hit this on btrfs fedora)
20:57clee: alyssa: I used to do all my builds in bind-mounted subdirs from /dev/shm/ and occasionally if I triggered a kernel panic while a build was going I would find random build objects in my filesystem under unexpected places like /etc (happened with ext2/3/4 and several others, never once with XFS though)
22:04ngcortes: hi all, running meson on my distro is currently having trouble finding rust crates when I'm building mesa. is there some special environment variable I need to set?
22:04ngcortes: ie. I'm getting "Run-time dependency indexmap found: NO (tried pkgconfig and cmake)" even after installing the indexmap debian packages
22:04ngcortes: I guess there could be a naming conflict or something
22:27dcbaker: ngcortes: Let me look, but I think if you want to use the distro installed packages you'll need to to call the package `indexmap-rs`. for reasons
22:28dcbaker: but it's also possible that Meson doesn't yet have sufficient support for using crates that are installed rather than built as part of the Mesa build process
22:28dcbaker:is a little out of the loop on the state of meson + crates