00:00 Company: has nobody started an llvm rewrite in rust yet?
00:00 gfxstrand: Regardless of the number of drivers record, I think I do now hold the Vulkan 1.3 speed-run record and I expect it'll stand for a while.
00:13 mareko: gfxstrand: how long did it take?
00:14 gfxstrand: mareko: Initial commit was May 16, 2022.
00:14 gfxstrand: And it included writing a new compiler from scratch as well.
00:14 alyssa: humble brag
00:18 mareko: yeah that's hard to beat
00:21 mareko: I don't know if you follow the news, but there are rumours that accuse NVIDIA of being a GPU cartel
00:23 CounterPillow: they're smuggling freshly grown GPUs from hidden plantations in the dense Amazon rain forest across the borders
00:34 airlied: CounterPillow: i hear they have submarines
02:27 alyssa: karolherbst: turns out what I really needed was https://gitlab.freedesktop.org/alyssa/mesa/-/blob/next/src/asahi/lib/shaders/geometry.cl?ref_type=heads#L237-251
02:28 karolherbst: that's not too bad
02:29 alyssa: not at all :)
02:29 karolherbst: btw
02:29 karolherbst: we should enable syntax highlighting in gitlab for cl files :D
02:30 alyssa: it works in mesa/mesa, but not forks, no idea why
02:30 alyssa: (compare: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/asahi/lib/shaders/geometry.cl 0
02:30 karolherbst: indeed...
02:30 alyssa: or https://gitlab.freedesktop.org/asahi/mesa/-/blob/main/src/asahi/lib/shaders/geometry.cl works too uh
02:31 karolherbst: you actually added the entry...
02:31 karolherbst: maybe gitlab being gitlab...
02:31 alyssa: Oh I know
02:32 alyssa: I bet it gets syntax defs from the main branch
02:32 karolherbst: ....
02:32 karolherbst: probably
02:32 alyssa: that seems appropriately gitlab
02:32 karolherbst: yeah, it makes perfect sense for gitlab to do it that way
02:33 alyssa: anyway, hopefully 1024 threads is enough for anyone..
02:34 karolherbst: should be
02:34 karolherbst: though I think AMD can do more?
02:34 karolherbst: but they also won't need that code
02:34 karolherbst: (for now)
02:35 alyssa: I mean for parallel stream compaction
02:35 alyssa: In theory M1 can do 24576 threads but
02:35 alyssa: hopefully people don't mind geometry shaders with primitive restart going at 4% of the max perf :p
02:35 karolherbst: :D
02:36 karolherbst: who needs that anyway
02:36 zmike: just cts and piglit
02:37 alyssa: zmike: and blender, disturbingly
02:37 alyssa: seemingly by accident
02:43 zmike: 🤕
02:57 DemiMarie: alyssa: blender bug?
02:58 DemiMarie: Also I find it interesting that GPU compilers need runtime libraries 😆
06:38 tjaalton: hmm no gfxstrand.. but "yes"
08:05 mripard: tzimmermann: can you do one last drm-misc-next PR? airlied agreed to do one last pull to unstuck msm
08:06 tzimmermann: mripard, sure
08:06 mripard: tzimmermann: thanks :)
08:35 pq: mripard, have you noticed how multiple emails from you through dri-devel list have identical Message-ID header?
08:36 mripard: pq: yeah, I noticed this morning too
08:36 mripard: it should be fixed now, but thanks for letting me know :)
08:36 pq: cool
08:43 mripard: I tried to be smarter than Konstantin at sysadmin, and failed hard :)
09:57 mripard: tomba: hey, it looks like you just pushed a patch to drm-misc, did you have any issue with the drm.git migration to gitlab ?
10:01 tomba: mripard: I've been a bit ill, I might have missed emails about that. But I can't find anything in my inbox... What should I look for?
10:01 tomba: mripard: so no, no issues, other than not knowing about it =)
10:01 mripard: tomba: if you didn't notice anything, I have my answer :)
10:02 mripard: but otherwise https://lore.kernel.org/dri-devel/dpfgauil5zvwkmitksv4qxa7vckl46ipp4nfpuzpgwi53j6oby@f2fcg6yj7l37/
10:02 tomba: oh, so I didn't do anything wrong? =)
10:02 mripard: no, you didn't
10:02 mripard: what I was asking is whether the upgrade mechanism we put in dim worked fine
10:02 mripard: if you didn't notice anything, then it's all working fine
10:02 sima: tomba, does your drm git remote you use for dim repos now point at gitlab?
10:03 tomba: yes, dim asked me to change the url, worked fine
10:03 sima: tomba, thx for playing guinea pig :-)
10:03 tomba: sima: yes, points to gitlab.
10:03 mripard: awesome, thanks :)
10:04 sima: tagr, just noticed https://gitlab.freedesktop.org/drm/tegra ... still planning to migrate to drm-misc?
10:04 sima: that repo seems a bit defunct, so wondered whether we need it when drm-misc has moved to gitlab
10:54 sima: tzimmermann, entirely aside and I didn't check, but re your dma_resv locking work: we must ensure that dma_resv_lock in atomic_commit code is _only_ called after commit_hw_done() has been called
10:54 sima: otherwise we might deadlock with the next commit since that one can wait for the previous to finish while holding the dma_resv lock
10:55 sima: (through the absolute maze that is called dma_fence)
10:55 sima: tzimmermann, which means you cannot take dma_resv_lock in end_fb_access
10:56 sima: (we might be getting this wrong already, in which case I'm going to put on the thousand yard stare and scream silently)
11:28 sima: jfalempe, do you have a link to the discussion for the new drm_panic_set_buffer design?
11:37 sima: jfalempe, asking because I liked that part of v7 a lot more, so kinda wondering what I'm missing
11:43 dj-death: anybody undersand why nir_opt_loop_unroll cannot easily unroll consecutive loops in the same block?
11:43 dj-death: I thought maybe starting from the bottom of the block and going up would do it
11:43 dj-death: but probably missing something...
11:49 tzimmermann: sima, the rework pushes the pin/unpin resv lock from callbacks outside into drm_gem_pin(), but the order of calls does not change. the issue with end_fb_access should not happen
11:49 tzimmermann: the changes to fbdev code are unrelated to end_fb_access
11:50 dj-death: danylo: looks like you might know ;)
11:53 tzimmermann: sima, there's no pin in end_fb_access, only vmap. vmap has already been fixed to not take the resv lock
11:54 danylo: dj-death No way I know anything about it =) I have a few commits there but that was long ago...
11:55 sima: tzimmermann, ah great
11:58 dj-death: danylo: yeah 4 years it looks like :)
12:15 sima: jfalempe, apologies that I entirely dropped the ball (at least I couldn't find the patch I've thought I've written), here's what I had in mind to fix the locking for your v7 design https://paste.debian.net/hidden/0ee26837/
12:15 sima: imo that's more robust than requiring explicit set_buffer calls sprinkled over drivers, but I want to understand the reasons for that design in v8 first
12:17 sima: https://paste.debian.net/hidden/41b28ebf/ added an important sentence about why it's safe to look at fb and gem_bo state
13:21 jfalempe: sima: it was suggested by tzimmermann here: https://lists.freedesktop.org/archives/dri-devel/2024-January/438240.html
13:22 sima: jfalempe, ah yeah I missed that :-/
13:22 jfalempe: but I'm fine with both design, the main issue with the set_buffer() approach is that it requires a call for each buffer flip, and for some driver, it's a bit complex to make sure the buffer set is always valid.
13:23 tzimmermann: sima, IIRC there was this problem of going over atomic state and trying to figure out if it has a valid framebuffer and where. so my suggestion was to tell the panic handler when/where a framebuffer is avaialble
13:26 sima: tzimmermann, yeah, and silly me forgot to actually type up the patch since I think I've figured out how to do it
13:26 sima: tzimmermann, https://paste.debian.net/hidden/9be7656c/ rough sketch, 90% docs
13:27 sima: but essentially even ttm based drivers I think can just access the relevant structures in panic context, as long as the trylock succeeds
13:27 sima: it means it's not perfectly synchronized to hw state when racing against a modeset, but I think that's ok and worth the simplification we get
13:29 sima: also this design would allow drivers to protect the scanout registers mmio writes with the raw spinlock and then maybe access vram with peek/poke registers (also protected by the panic lock)
13:29 sima: and we'd actually be perfectly in sync with hw state
13:29 sima: if people feel like that's worth it
13:29 sima: but it does assume the get_scanout_buffer callback form v7
13:30 jfalempe: sima: thanks for this patches, I don't know enough the drm internal to write this on my own.
13:30 jfalempe: I will work on a v9, with going back to the get_scanou_buffer from v7
13:36 sima: jfalempe, maybe hold a bit before we reach consensus :-)
13:36 sima: also I think if we do have a driver where the set_buffer approach is best, we could still add that
13:36 sima: and I just realized that the window of new sw state, but not yet in hw shouldn't be that big
13:36 sima: the big hold-up is if the atomic needs to wait for fences
13:37 sima: and if those are not signalled yet, then we have excellent chances that the gpu is still rendering, so probably going to overwrite our panic stuff still
13:37 sima: since the gpu doesn't die with the cpu/kernel on panic
13:38 sima: also I have meetings now and then I'm off for dinner in zürich, but I'll check scrollback for more discussions tomorrow
13:38 sima: since I'm not sure what I typed up in the kerneldoc is actually correct :-)
13:44 jfalempe: sima: in the panic handler, we can wait a bit if the gpu is still rendering, but by doing active polling, not by sleeping.
13:44 sima: uh polling sounds dangerous
13:45 sima: also I think I got it the wrong way round, since in this case the buffer that's shown is not the one being rendered to
13:46 dogukan: libdrm states that GEM handles are unique to DRM file descriptions and they should be reference counted in user space. So, what is the expected behavior after a fork? We would have two processes that have an fd to the same DRM file description, with different address spaces.
13:46 dogukan: Or is forking even allowed in this case? I see that struct drm_file keeps a tid to the process owning the file. In this case, we would have two processes having access to the same drm_file.
13:51 pq: dogukan, you can fork, and both processes then have the same open DRM device file, and they will screw up that reference counting.
13:53 pq: AFAIK the same happens if you send DRM device fd to another process via IPC, too. Just don't do it.
13:57 pq: As a rule of thumb, always set CLOEXEC and exec immediately after fork in the child process.
14:15 DavidHeidelberg: eric_engestrom: Heya, what would think about publishing also sha512 for new releases?
14:37 eric_engestrom: DavidHeidelberg: I don't see the point, but I also have no objection
14:37 eric_engestrom: the release email already has that, so I assume you're talking about the release note for the website?
14:40 eric_engestrom: honnestly, I'm not sure I see the point in copying the checksum into the release notes at all, especially since the tarball link is not even there
14:40 eric_engestrom: I would be in favour of dropping the checksum from the relnotes
14:44 eric_engestrom: or adding the tarball link (and then we can generalize "SHA256 checksum" into eg. "Tarball checksum" and have put everything from the xorg release script in there)
14:45 mattst88: emersion: tl;dr instructions for making a pixman release these days?
14:45 eric_engestrom: ("everything" = https://gitlab.freedesktop.org/xorg/util/modular/-/blob/5463385fcd137e370204bc92578cafaa513b4967/release.sh#L131-134)
14:45 mattst88: I'd like to make one for the big endian fix as well as the clang/arm32 patch I just fixed
14:45 emersion: mattst88: there is a script which should do the right thing
14:46 emersion: am away for now, but can give more details in a few
14:46 mattst88: emersion: not in tree, right? IIRC you posted it somewhere?
14:48 daniels: mattst88: https://gitlab.freedesktop.org/xorg/util/modular/-/blob/master/release.sh
14:48 daniels: not that I see anything about pixman there, but
14:50 emersion: pixman never used that script
14:51 emersion: it had a custom script baked into autotools before
14:52 sima: pq, you can send around the fd, but really only before you've done anything with it
14:52 sima: or at least only one process is allowed to allocated buffers
14:52 sima: like logind keeping drmfd around so it can force the vt switch if the compositor doesn't cooperate
14:55 DemiMarie: sima: will Linux be able to produce a BSOD like Windows can?
14:55 daniels: emersion: ah, sorry for the noise
14:56 jfalempe: DemiMarie: I'm working on it, see the drm_panic commits on dri-devel
14:56 pq: sima, are you saying that is it ok to share the fd first, and then *both* processes can start creating and destroying GEM handles to dmabufs shared between each other? :-)
14:57 DemiMarie: jfalempe: nice!
14:58 pq: I think the safe path on sharing DRM device fds is so narrow that I'd just say "don't do it".
14:58 sima: pq, yeah maybe not that :-)
14:58 sima: pq, well both dri2 and logind massively share them by design, but yeah it's very narrow indeed
14:58 sima: gtg head out for dinner in zürich now, ttyal
15:06 mattst88: daniels: yeah, would be nice if it used that script. I've used that script 100 times :)
15:19 emersion: mattst88: the release scripty i used is in https://gitlab.freedesktop.org/pixman/pixman/-/issues/86
15:19 emersion: ideally we'd migrate to GitLab release assets instead of SSH
15:19 emersion: but that script mimcks what the autotools stuff was doing
15:29 mattst88: thanks!
16:19 austriancoder: DavidHeidelberg: what do I need to do if I want to use my own kernel to test something out in CI? I tried: https://gitlab.freedesktop.org/austriancoder/mesa/-/commit/3a2fa8230b001c78615990af01089fb440c7bd88
16:19 austriancoder: eric_engestrom: ^
16:30 mattst88: emersion: is it intentional to generate sha512 only for the tar.gz, and to only gpg sign that file?
16:31 mattst88: the tar.xz only has a sha256sum and neither tar.gz/tar.xz's sha256sum has an associated .asc
16:31 eric_engestrom: austriancoder: are you using ci-tron? if so, `B2C_KERNEL_URL` is what you're looking for
16:32 austriancoder: eric_engestrom: not yet.. but I think I got it working. Looks like BM_KERNEL and friends is still working
16:32 daniels: eric_engestrom: iwbni that was the same variable as the other platforms
16:33 eric_engestrom: daniels: do other platforms use a common var?
16:34 emersion: mattst88: that's what the old script was doing
16:34 emersion: i doesn't make much sense, the pgp signature also does a hash…
16:35 mattst88: emersion: okay, thanks. I guess I hadn't noticed before
16:37 eric_engestrom: daniels: lava has KERNEL_IMAGE_BASE which serves as a prefix with /$arch/$image_variant appended
16:38 eric_engestrom: whereas ci-tron has B2C_KERNEL_URL which is the kernel itself
16:38 eric_engestrom: so we can't really make them use a single var
16:39 eric_engestrom: but I take your point that it would be nice to unify what can be unified
16:41 daniels: well, we could just as easily make LAVA use $HW_KERNEL_URL or whatever too, right
16:59 eric_engestrom: yeah actually, we could have a single kernel url var and if it's not set, fallback to the current respective mechanisms
17:01 daniels: ++
18:46 bl4ckb0ne: "libdrm_intel" is supplied by libdrm right?
18:51 daniels: yeah
18:52 bl4ckb0ne: is it checking for subprojects or always taking the system one ?
18:53 daniels: 'it'?
18:53 bl4ckb0ne: meson
18:53 bl4ckb0ne: trying to build mesa on bookworm
18:58 cheako: bl4ckb0ne: They just removed support for llvm-14/bookworm.
18:58 bl4ckb0ne: oh so I wont be able to build mesa at all
18:59 cheako: Just not the latest git, you'll have to go back to when that was removed(a few days ago).
18:59 cheako: "AFAIK"
19:01 cheako: You could upgrade llvm I just found https://apt.llvm.org/ but also backports or testing.
19:03 DemiMarie: I’m surprised that LLVM is not a subproject.
19:03 bl4ckb0ne: seems like 16 is there
19:03 bl4ckb0ne: it is DemiMarie
19:03 mattst88: do I understand correctly that bookworm was released ~6 months ago with a version of llvm from 2 years ago?
19:04 DemiMarie: bl4ckb0ne: Ah, I see. Given how long it takes to build I am not surprised you do not want to build it yourself.
19:04 bl4ckb0ne: i have 13, 14, 15 and 16 in the repos
19:06 cheako: Need 15 at a min: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27141
19:06 bl4ckb0ne: should be good
19:16 bl4ckb0ne: now I just got to get that libdrm wrap file to work
19:17 bl4ckb0ne: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26835 hm
19:21 eric_engestrom: bl4ckb0ne: feel free to comment in !10364 :)
19:21 bl4ckb0ne: will do, thanks
19:22 eric_engestrom: fwiw, both amd and nouveau are trying to merge the driver-specific parts of libdrm back into mesa and drop the dependency on libdrm_${driver}
19:22 bl4ckb0ne: yeah ive been loosely following that
19:22 eric_engestrom: you could probably convince intel to do the same
19:22 bl4ckb0ne: in wlroots we just have the "fallback" field set and users clone their own repo, its very convinient
19:23 eric_engestrom: especially since I think only i965g still uses libdrm_intel, all the other intel drivers use the mesa code for this
19:23 eric_engestrom: so likely most of it is already there for i965g too
19:24 eric_engestrom: *i915g
19:26 bl4ckb0ne: should I bother submit a patch for the `fallback` field or just leave it uncommited and hope for a change in the future
19:26 eric_engestrom: bl4ckb0ne: here, you mean? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson.build#L1686
19:27 bl4ckb0ne: cheako: 16 in bookworm is blocked by not having llvmspirvlib for 16
19:27 eric_engestrom: yeah, post it, we'll see what people reply
19:28 bl4ckb0ne: basically what emersion proposed here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10364?commit_id=40b87cde2ac6824d9827d897b9971c004c6c6586#note_1182371
19:45 bl4ckb0ne: beside a few missing deps not caught by meson, I got latest mesa git built on bookworm
20:53 jcnrot: I had fifty line java trace when my father moved to shitland with me. I looked at this trace as open source big gun, and said wau watta trace. Now i am inspecting traces every day, today for an example there was a trace of poop when i left, i was inspecting it close to get a real feeling, nose was entirely in da shit.. I gotta say wau about that trace , only thing that is totally fair to say is just wau. MWK makes poopy fartix type of activity and
20:53 jcnrot: karolherbst sniffs very close, NOT a single aroma is skipped. Karol is sucha grand fartsniffer imho. what a hero.
21:01 jcnrot: Scala is much unmaintained, matrix has only support page, and i do not get it how to call those iterators , biggest issue is even when they really turn out to iterate over the divisor and modulo, then i would not, know how to call the division and modulo and respective multiplication without iterator
21:01 jcnrot: such as unrolled access routines
21:14 jcnrot: they access something by taking a divisor and ANDing modulo of that element and that should return the element, but without iterator i have no clue how that would work
21:19 DemiMarie: can someone kick them?
21:22 jcnrot: Technically it should be possible with some checkpointing kit or debugger, cause division is repeated subtraction and multiplication is repeated addition, so you would want to checkpoint how many times to add or remove to access certain elements.
21:44 jenatali: Ugh. I'm getting some bad loop unrolling behavior. `for (int i = 1; i <= limit; ++i) { arr[i] = foo; }` is giving me out-of-bounds accesses to `arr`
21:47 jenatali: Loop analysis sees the induction variable is used to access the array, but misses the fact that it starts at 1, so it sets the loop iteration count to the size of the array, when it needs to be -1
21:52 jenatali: Any nir experts around? Or anyone familiar with loop analysis?
22:00 cheako: I always brute-force off by one issues, try `i < limit`.
22:01 jenatali: It's not my shader, it's part of Geekbench
22:02 cheako: What's `limit` as compared to how many indexes `arr` has?
22:06 jenatali: limit is an unknown variable. Loop analysis isn't figuring out how many iterations using it
22:11 cheako: I assume C style semantics, https://onlinegdb.com/hh1N3xoKZ A value `size-1` for limit as in `5 - 1 = 4`would be correct. Yeah, if limit is coming from elsewhere it must be validated somewhere hopefully external to the shader.
22:13 cheako: If you set `limit = 5`, then the stack smashing detector is triggered.
22:13 jenatali: Ok it's actually taking the `i = 1` initial condition into account, it's just that the terminating condition of `i <= limit` is tripping it up. Since the loop's *actual* limit is an inclusive limit, but we're guessing an upper bound based on array accesses, which is an exclusive limit
22:14 alyssa: jenatali: not the first time <= conditions confuse loop analysis :~(
22:14 jenatali: Yeah...
22:17 jani: PSA: dim now supports applying patches using b4 with the new b4-shazam and b4-shazam-branch subcommands. please try them out and report about any hiccups.
22:57 jenatali: Yeah the array out-of-bounds logic in nir_opt_loop_unroll is busted too. It assumes that the induction var's value is going to be == the trip count, which is wrong for loops starting at nonzero values or not incrementing
22:57 jenatali: Fun
23:00 alyssa: womp
23:06 cambrian_invader: should drm_bridges have internal locking e.g. between the HPD IRQ and atomic_enable?
23:09 cambrian_invader: I notice that e.g. msm does this