07:37 jani: airlied: how about that drm-misc-next pull request that mlankhorst kindly sent? https://lore.kernel.org/r/23ded62c-6a62-4195-9c08-4dfb81eafd72@linux.intel.com
08:41 dolphin: airlied, sima: drm-intel-next-fixes PR sent, the CI looks bit ugly before there is a backmerge of later -rc than -rc1
10:58 jadahl: is there some proper way to detect whether a i915 driven gpu is dedicated or integrated? currently looking at code that just compares the DEVPATH against /devices/pci0000:00/0000:00:02.0/drm/* but is there no better way than that?
11:02 dolphin: jadahl: why is that a bad way?
11:05 jadahl: I don't know, is it? seems a bit arbitrary to me
11:05 dolphin: well, other ways are to check the presence of the VRAM or not
11:06 jadahl: right
11:07 dolphin: or maybe hwmon directory, but it's all kind of indirect
11:08 jadahl: checking for vram presence is what's done for the xe driver
11:08 jadahl: can one do that with i915 as well?
11:08 jadahl: from userspace
11:09 dolphin: sure, there is ioctl to query it: https://elixir.bootlin.com/linux/v6.15-rc6/source/include/uapi/drm/i915_drm.h#L3566
11:09 emersion: jadahl: vulkan has a device type field
11:10 emersion: jadahl: also there is https://github.com/KhronosGroup/EGL-Registry/issues/206
11:10 jadahl: interesting
11:11 jadahl:goes and links to that
11:11 emersion: happy to help pushing this along if you're interested
11:12 jadahl: the context is switcheroo-control, so using vulkan or EGL is roughly the same (it uses none so far)
11:12 dolphin: jadahl: however "comparing DEVPATH" sounded more like you are writing a shell script?
11:12 jadahl: dolphin: it's an udev rule
11:13 dolphin: I'm pretty sure DEVPATH is a solid way for i915 at least, you're only really covering dg1 and dg2
11:14 jadahl: dolphin: ok, good to know, thanks
11:20 jfalempe: tzimmermann: Hi, may I push this https://patchwork.freedesktop.org/series/147997/ to drm-misc-next, or should I wait for more reviews?
12:07 tzimmermann: jfalempe, i've already looked over an earlier rev and v3 seems quite nice. i'd say it's ready to go in
12:07 tzimmermann: regressions in such changes tend to be easy stuff were something simply got lost; so no big deal
12:26 pixelcluster: eric_engestrom: dang, it looks like https://gitlab.freedesktop.org/mesa/mesa/-/commit/45235bf73c741271974d34b6d9024fbad589d3fb broke during backporting :/
12:27 pixelcluster: it's quite an insidious issue - on 25.1+, where the commit was backported from, "radv_disable_dedicated_sparse_queue" is correct, but on 25.0.x it should be "radv_legacy_sparse_binding"
12:27 pixelcluster: what's the best way to fix this here - MR against staging/25.0?
12:28 jfalempe: tzimmermann: thanks, I will push it.
12:29 kisak: ^ yes, non-trivial backports should be merge requests against the staging branch so that the extra info around the non-trivial change is retained
12:46 javierm: jfalempe: I didn't answer because I was the one who acked the patch but I agree with tzimmermann that usually there's no reason to way that much for changes like this
12:47 tzimmermann: javierm, hi. i'd also like you to look over the lut-update series
12:48 jfalempe: javierm: ok, thanks, I will be more pro-active next time :)
12:50 javierm: tzimmermann: sure! I can take a look tomorrow. I didn't look in detail because I noticed that jfalempe was already reviewing it :)
12:51 javierm: jfalempe: that's OK. I should also be better at pushing patches that I review/ack
12:51 javierm: it's just that I never know if the person posting already has drm-misc rights to push or not
12:53 tzimmermann: javierm, there are two drivers of yours affected
12:54 javierm: tzimmermann: right. I'll review it. Thanks!
12:55 tzimmermann: thank you
12:56 tzimmermann: javierm, jfalempe, https://people.freedesktop.org/~seanpaul/whomisc.html
13:04 javierm: tzimmermann: oh, I didn't know there was that
13:15 javierm: tzimmermann: hmm, the commiter heuristic seems to not be accurate
13:42 tzimmermann: javierm, IDK how up-to-date this list is
16:14 MrCooper: emersion: could have just moved https://gitlab.freedesktop.org/mesa/drm/-/issues/116 to the proper project :)
16:14 emersion: MrCooper: i wanted the reporter to follow the proper template there
16:15 MrCooper: k
19:19 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/76458538
19:19 alyssa: v3d kernel oops
19:20 alyssa: not sure who works on v3d.ko these days
19:20 alyssa: mairacanal: maybe? ^^
21:02 eric_engestrom: pixelcluster: oh no, "drirc option was renamed" is something that I had not even though of as a possibility when applying backports :/
21:03 eric_engestrom: I see your MR; merging it :)