03:30 Lynne: I am not happy the kernel's OOM killer kills completely innocent programs when a single program allocs too much GPU VRAM on a GPU that runs and gets used by absolutely nothing
03:31 Lynne: and I mean I'm unhappy enough to start trebucheing glitter bombs, first targetted, and then just in general as collective punishment
03:38 soreau: isn't that the part where it should evict (the bo) to ram?
06:42 tomba: tzimmermann: 1ae7fe832c2d3ecc75815eed037a07290586b6be had a merge issue, breaking compilation for sound/soc/ti/omap-hdmi.c, now in linux-next. I have sent a fix "[PATCH] ASoC: ti: omap-hdmi: Fix build error from a merge commit". drm-misc fixes branches haven't been updated so I can push there. Could you merge and push the fix to get linux-next compiling?
06:43 tzimmermann: tomba, give me a bit to update the branch. i'll ping you
06:45 tzimmermann: tomba, but do you really need drm-misc-fixes then? that merge is in drm-misc-next and putting your patch there should already fix linux-next, i think
06:45 tomba: hmm, or should it just be in drm-mi... right...
06:46 tomba: I always get confused with all the branches. Let me get more coffee and think again =).
06:46 tzimmermann: airlied ^ ?
06:53 tomba: Right, so the merge commit is only in drm-misc-next and the for-linux-next branches. So pushing to drm-misc-next indeed sounds right.
07:02 tomba: I've pushed the fix. Does drm-misc-next flow automatically to linux-next, or is there a manual merge step in between?
07:13 airlied: automatically
07:21 tomba: thanks
07:58 pq: Using udev/uevents for monitor hotplug does seem a little strange given that monitors are not meaningfully represented in udev. One would expect things like the non-desktop property to be set by udev rules inspecting EDID, and EDID overrides set by udev rules. Why not (parametric) color profiles as well.
08:05 emersion: pq, would one expect that? input configuration is not performed via udev, for instance
08:06 pq: emersion, there are lots of udev rules for input devices, libinput depends on those.
08:07 pq: device type particularly comes to mind
08:09 airlied: we kinda ended up in the drm isn't linux specific hole while udev objects were being defined for others
08:10 pq: emersion, https://wayland.freedesktop.org/libinput/doc/latest/device-configuration-via-udev.html#udev-device-type
08:13 pq: airlied, which way would you climb out of that hole, or is it comfortable enough?
08:16 airlied: pq: with the whole drm master concept I feel udev is often a bit like shouting to the system when you know the consumer already, but I do like the idea of announcing hw changes to the system as well
08:17 airlied: so I think we are in a comfortable spot which isn't the worst of both worlds
08:17 airlied: like you said the whole edid overrides and quirks being udev led feels like the proper answer
08:18 airlied: but does it buy us anything other than it fitting in with others, I don't know, and probably can't say if we'd find some benefits in doing it that way
08:19 pq: right
08:19 emersion: pq, i don't want to lean on udev too much
09:47 tzimmermann: mripard, i have a patch series for pushing vga_switcheroo further into DRM's fbdev client. I'm quite sure who to ask for a review on the DRM-side. maybe could you take a look? https://patchwork.freedesktop.org/series/169932/ thanks
09:48 tzimmermann: jfalempe, ^ drm_log does use/need vga_switcheroo, but maybe you want to keep an eye on these changes as well
10:16 airlied: tzimmermann: that merge next into misc-next leaves amdgpu kunit tests failing to link
10:16 airlied: undefined parse_hdmi_amd_vsdb
10:16 airlied: ah I see a patch on the list
10:44 tzimmermann: airlied, i see, thanks. i'm going to pick up the patch and merge it now. this one, right? https://lore.kernel.org/dri-devel/20260820142802.1342066-2-rodrigo.vivi@intel.com/
10:48 airlied: tzimmermann: yes
10:55 tzimmermann: agd5f, ^ before i do something stupid: how come that patch is in amd trees, but did not make it into drm-misc-next in the last 2 weeks? i synced from drm-next yesterday. should this fix not come with it?
10:57 emersion: bjorn3_gh: race between enabling notifications and getting current state
10:59 emersion: perhaps something else to watch for: events currently include a few optional fields such as object/property IDs
11:38 mripard: tzimmermann: will do
11:38 mripard: maybe not today, I have lucaceresoli series to do first
11:46 tzimmermann: thnaks a lot
11:46 tzimmermann: 'thanks'
13:56 agd5f: tzimmermann, it's not in the amd trees. Will merge it to drm-misc now
14:00 tzimmermann: i see, i thought from your reply
14:00 tzimmermann: thanks for merging it
14:01 agd5f: yeah, I wasn't sure where the conflict was when I initially replied
14:56 mripard: tzimmermann: does https://lore.kernel.org/all/effc093c-646d-451a-aa9a-4ee0334d75ae@suse.de/ means acked/reviewed-by ?
15:07 agd5f: anyone know how to resolve this error with drm-tip? I've fixed all the conflicts, but I can't seem to get rid of that: https://paste.centos.org/view/cbb7e987
15:12 agd5f: tzimmermann, airlied, sima ^^^
15:33 tzimmermann: agd5f, i'd say the existing fixup patch needs to be adapted.
15:33 tzimmermann: my guess is: revert the resolution and do it again https://drm.pages.freedesktop.org/maintainer-tools/committer/conflict-resolution.html#removing-a-wrong-conflict-resolution
15:34 agd5f: tzimmermann, I tried that, but it seems to keep getting applied
15:34 tzimmermann: 'revert the fixup and do the conflict resolution'
15:34 tzimmermann: agd5f, did you double check on point 1 of that list?
15:35 tzimmermann: that seems the 'fun' part
15:36 agd5f: tzimmermann, I thought so
15:36 tzimmermann: will i see the issue when i do a rebuild tip here?
15:37 agd5f: yeah, I think so
15:38 tzimmermann: i'll try to reproduce. no promises made :)
15:41 tzimmermann: i see it
15:42 tomba: tzimmermann: I only now realized that you weren't cc'd in Mark's original linux-next build breakage mail, nor the one he send today ("linux-next: build failure after merge of the drm tree"). so, jfyi, as your merge brought in the original breakage =). in his today's mail I think he's referring to the parse_hdmi_amd_vsdb issue, which is now fixed.
15:46 tzimmermann: agd5f, fixed now for me
15:47 tzimmermann: AFAICT you did a fix-up commit 392b14d16d569 in drm-rerere that removed these interfaces
15:47 tzimmermann: and it now conflicted with the actual patch
15:54 agd5f: tzimmermann, that's what I thought I reverted. thanks for the help
15:58 tzimmermann: you're welcome
18:58 marcinkolacz: mesa#15904 (RADV, gfx1200): ACO abort on @store_deref during compute pipeline compilation in an Unreal Engine 5.8 title. I'm the game's developer, it's a released Steam title, and I can give free keys to anyone who wants to reproduce it. A second reporter sees the same on RDNA3 (Navi 32). Happy to provide NIR dumps, a Fossilize capture, or a stripped-down repro case.
21:00 zmike: pendingchaos: ^
21:19 FireBurn: I've got a R9700 pro, happy to help debug if it'll hellp
23:46 orowith2os[m]: test
23:46 orowith2os[m]: yay!
23:46 orowith2os[m]: bridge works now!
23:48 orowith2os: perhaps my name works now?
23:48 orowith2os: yayy!
23:50 orowith2os: now I think I'm all set up
23:51 karolherbst:waves to orowith2os
23:52 orowith2os: hihi!
23:52 orowith2os: I was going to ask about proposing an EGL extension to allow clients to set tearing for Wayland?
23:53 orowith2os: either allowing eglSwapInterval to be -1 to hint tearing, or an explicit extension for Mesa to take a boolean to set tearing or not.
23:53 orowith2os: eglSwapInterval can't use 0 to set tearing because clients rely on it to mean mailbox, especially toolkits and web browsers and the like.
23:55 orowith2os: either that or a change is added to specify that Mesa doesn't bind tearing-control-v1 so some LD_PRELOAD or clients can bind to it instead.