10:28 zzag: emersion: can you please have a look at https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/430 ? our ci is currently on fire due to the faux changes in the kernel, but with libdrm 2.4.126, we'll have even more serious issues :(
10:30 emersion: i'll have a look
10:31 zzag: Thanks!
10:33 zzag: Regarding drmDevicesEqual(), I also looked whether deviceinfo.faux->name can be used, but it's just vgem which is really not a lot of information
10:33 zzag: it's just "vgem"
10:33 zzag: also I'm pretty sure that memcmp() won't unreference nested "char *name"
10:33 zzag: in the fauxinfo struct
10:34 zzag: if it were "char name[SOME_LENGTH]", it would be fine though
10:35 zzag: but in short term, we would really like to get the crashes fixed
10:43 emersion: when things were on the platform device, we were comparing the string "vgem":
10:43 emersion: s/://
10:46 zzag: Huh, in that case, perhaps we could remove the if statement over here https://gitlab.freedesktop.org/mesa/libdrm/-/blob/main/xf86drm.c?ref_type=heads#L4517 ?
10:46 zzag: this makes me wonder about vkms though
10:46 zzag: if it registers multiple primary nodes, "vkms" won't be a great identifier :D
10:48 emersion: hm, yeah, and that will definitely happen in the future
10:48 emersion: also… drmDevicesEqual is used all throughout the ecosystem
10:49 emersion: returning false for a matching device will break compositors and clients under vkms
10:50 emersion: tbh that function is not very nice
10:52 emersion: relying on per-bus checks is not great just for checking if two devices are the same
10:52 emersion: i'm not sure it's even correct for say USB
10:53 zzag: if deviceinfo.faux were populated, it'd return false anyway because of https://gitlab.freedesktop.org/mesa/libdrm/-/blob/main/xf86drm.h?ref_type=heads#L894. the name string is allocated on the heap https://gitlab.freedesktop.org/mesa/libdrm/-/blob/main/xf86drm.c?ref_type=heads#L4491, so memcmp() shouldn't return 0 because name pointers are different. Although it should be fixable, e.g. by using strcmp()
10:54 emersion: yeah we don't necessarily need to use memcmp() for comparing
10:54 emersion: another way to solve this would be to populate the bus info with _something_
10:58 emersion: we could for instance try to grab the dev_t of the underlying faux device
11:10 daniels: afaik the name will be different if you do create multiple vkms devices?
11:11 emersion: i don't think so, it's a fixed string
11:12 emersion: https://lore.kernel.org/all/2025021029-snout-swivel-9a45@gregkh/
11:12 emersion: faux_device_create(DRIVER_NAME, NULL, NULL)
11:12 emersion: and that just calls dev_set_name() with that name
11:13 emersion: but it's "fine": conceptually it's not very different from buying two identical GPUs and plugging in both
11:13 emersion: the businfo though needs to be different somehow
11:15 daniels: emersion: right, but now vkms can only have a single device ... iirc from Louis's dynamic patches that it could have dynamic name too
11:15 emersion: ah
11:16 emersion: but is that a guarantee? does the kernel refuse to create two devices with the same name?
11:18 daniels: I'd assume so, given the existence of `/sys/bus/faux/devices/$name`?
11:20 zzag: emersion: should I then change the patch so libdrm properly compares the names? also should I add a new businfo type or is it fine to reuse deviceinfo.faux (it'll be a bit awkward but it'll also be identical to the businfo counterpart)
11:31 emersion: in that case, maybe it would be more correct to stuff the faux device name in businfo…
11:32 emersion: but dropping the faux deviceinfo would be a breaking API change
11:33 zzag: hmm, okay. Do you happen to know if faux devices have a max name length?
11:34 zzag: max platform name is `#define DRM_PLATFORM_DEVICE_NAME_LEN 512`
11:36 tzimmermann: mripard, i take over drm-misc-fixes this week
11:39 emersion: > @name: The name of the device we are adding, must be unique for all faux devices.
11:40 zzag: "hmm, okay. Do you happen to know if faux devices have a max name length?" I guess we are limited by the max filename length `NAME_MAX`, which is 255. not sure where 512 comes from then, maybe for future-proofing
11:40 mripard: tzimmermann: ack :)
11:48 mripard: $
13:24 lumag: mripard: Yes, it's on my plate, but it takes more time, especially since older platforms are very picky about the cursor updates.
13:29 mripard: lumag: ack, thanks for having a look :)
14:27 zzag: emersion: updated the MR, the code is somewhat meh, but drmGetDevices2(0, NULL, 0) doesn't crash anymore; also primary and render nodes of vgem are merged in a single drmDevice as expected
16:10 EKC: Hi I was wondering if there's any additional documentation for NAK for the Nvidia driver? I was reading some papers on instruction scheduling optimizations for NVIDIA GPUs and the literature is a bit sparse to say the least
16:12 EKC: as far as I could tell NAK is the only open source tool to target that instruction set that isn't just an assembler (and most of those seem like they are mostly intended for research purposes)
16:20 alyssa: I mean you can read the code, it's well written & well commented
16:24 EKC: oh don't get me wrong I'm not complaining, it is very clean code
17:21 glehmann: EKC: for scheduling in particular, you might also be interested in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33306
18:13 Hazematman: anyone else finding fdo gitlab slow today, or is it just something on my end?