06:54 dolphin: daniels: Do we have a process for AI slop security reports? https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15882
06:57 dolphin: (More details at: https://lists.freedesktop.org/archives/intel-gfx/2026-March/388178.html)
07:44 dolphin: airlied, sima: drm-intel-fixes PR sent
08:25 sima: Company, airlied I think unless it would have read&understood all the m-l discussions the past few years probably no way, because not even the kerneldoc spells out the common pattern in how drivers tend to be buggy
08:26 sima: there's some FIXME in there though that I think should have at least humans started wondering about the bigger context of this entire area
08:27 sima: mlankhorst, maybe follow-up rule of thumb for use-after-free on hotunplug: unless the memory is refcounted like for devm_drm_dev_alloc it's generally a bug if you free memory from devm/hotunplug/remove
08:27 sima: or "devm_kmalloc considered harmful"
08:28 sima: and at least the current design we have is that we pile everything up on top of the one drm_device refcount
08:29 sima: airlied, I think the generated one is surprisingly good, but it misses even super-basic big picture stuff like "hey don't put two bugfixes into one patch"
08:30 sima: or "hey your changing calling context of fb cleanup, this needs to be consistent everywhere and needs driver consensus and updated kerneldoc"
08:31 sima: I do wonder whether clear instructions to chase down kerneldoc plus trying to improve that would actually net us much improved kerneldoc as a side benefit of lighting up all that vc cash and boiling all that water
08:32 sima: at least for api-usage details it should be able to infer important rules
08:35 sima: the stuff in there at least looks like it's stuck at "I've read the functions you're calling" and not anything more in-depth
10:07 mlankhorst: Yeah it came from the wrong assumption that since I touched the display code for xe, we've mostly been able to beat constructors/destructors into a well-behaving shape
10:53 Company: sima: could also go the other way: you could tell the AI to improve/review/criticize the docs?
10:53 Company: and then once the docs are fixed tell the AI to use those docs to improve the code. And then use the code to improve the docs. And then...
10:53 sima: I think it should be pretty decent at creating some text for a change and stuff like that, yes
10:54 sima: I'm not sure it can fill in the high/design-level docs we'd need for stuff like this
10:55 sima: but yeah I wondered whether it could help with the "I have no idea how to write docs" people we have for when they create new libraries and stuff, should at least get a baseline for future improvement in place
10:56 sima: at least my impression is that people mostly dread that baseline boilerplate in writing kerneldoc
10:57 sima: only downside is that docs with too much boilerplate lose value, often the hard part is decided what to leave out so that the really important bits don't get lost
11:33 Company: I was thinking about docs that are old and have gone out of sync with the actual code
11:33 Company: and using llm to find those parts and udpate (or delete) them
12:10 mlankhorst: Well that would be something a LLM could be good at, perhaps not update but definitely categorise those
12:10 mlankhorst: speaking of which
12:19 mlankhorst: Company: https://patchwork.freedesktop.org/patch/714428/?series=163914&rev=1 O:)
12:20 mlankhorst: Took a bit of effort to see where the comment came from, likely the same patch applies to i915 too
12:27 mlankhorst: sima: should I inform -stable on the regression?
12:46 pq: emersion, oh right, reading the DRM_FORMAT_Y8 paths, I remembered another thing it actually mentions there: when you take an Y8 and expand it to YCbCr, the Cb and Cr shall be neutral (however 0.0 is encoded).
12:46 pq: It also says R8 expands to (r, r, r) rather than (r, 0, 0), so I guess I remembered that wrong.
12:47 pq: s/paths/patch/
12:48 sima: mlankhorst, Fixes: is enough
12:49 sima: they'll pick it up
12:49 pq: Cb and Cr are nominally -0.5 .. 0.5 (or maybe -1 .. 1), so the uint8 encoding of 0.0 is probably 128, not 0.
12:49 sima: mlankhorst, that mtrr line is a fun bit of lore :-)
13:02 mlankhorst: Yeah when I saw it, it had to have some kind of history that probably predated KMS
13:54 MrCooper: sima: I also though Fixes: was enough, but GKH LARTed me that Cc: stable is required, they pick up Fixes:-only as best effort because many people get it wrong (surprise, since it seems to work fine)
13:54 MrCooper: *thought
14:59 sima: MrCooper, oh I thought it's moved to "Fixes: is enough" a while back, but I guess then there was too much backlash for stable picking up stuff that fixes benign things like spelling mistakes
15:01 sima: MrCooper, but yeah also understood mlankhorst 's question as whether he needs to send a separate mail to stable, just cc: stable/Fixes: like for everything else should be enough
15:14 zmike: mareko: does opt_varyings do any code motion related to viewIndex ? it seems like it should be possible to move fs conditionals depending on it backwards into geometry stages
15:54 Ermine: Weird situation with gputop: when run as root, it shows systemd on card1. When run as user, it shows gnome-shell.
15:55 mareko: zmike: it doesn't do that, but it's possible to do
15:56 zmike: would be hugely beneficial in the VR space
16:01 mareko: zmike: is that space using mostly GL or VK?
16:01 zmike: definitely both
16:01 zmike: android is all GL, desktop is mostly VK
16:02 haagch: godot has an opengl and a vulkan renderer. opengl is recommended for android and vulkan for desktop, but at least with the godot xr game jam entries about half the linux builds use the opengl renderer anyway
16:04 mareko: zmike: it can only move code from FS to VS and TES like that
16:04 zmike: sure
16:05 zmike: that case is definitely hit
16:05 haagch: gotta ask bastiaan what godot will recommend for the steam frame. it's technically a standalone xr headset where they recommend opengl for, but it's also running on freedreno/turnip
16:06 zmike: mareko: I'm thinking it should be possible in most cases to eliminate all viewIndex access in FS
16:06 zmike: which I think would be a huge win since the VS already has to access viewIndex for geometry
16:31 mareko: do you know what would also be a huge win... AMD drivers using the second pos output to generate 2 positions from VS
16:33 glehmann: yeah, but it's kind of annoying that we have to support 6 views
16:33 mareko: why 6 views?
16:33 glehmann: spec requires it
16:34 bbrezillon: tzimmermann: did you have time to look at https://yhbt.net/lore/dri-devel/20260320151914.586945-1-boris.brezillon@collabora.com/ ?
16:38 mareko: it's 6 because it can be used for cubemap rendering, though we just need 2 for VR; AMD hw could squash 6 layers into 3 draws
16:43 mareko: but 6 separate draws with a user SGPR change is slower than doing the same thing with 1 instanced draw, so we aren't gaining anything by emulating multiview completely
17:09 mareko: zmike: I'm working on it
17:12 zmike: awesome
17:12 zmike: thanks
18:08 tzimmermann: bbrezillon, a-b: /me
18:37 zzyiwei: clear