00:36llyyr: if i see a validation layer with radv and anv, but not with llvmpipe, is it possible that it's a driver bug?
00:37llyyr: validation layer warning*
01:34robclark: or just different driver/hw capabilities and bad assumptions in app... first assumption is app bug
08:20jfalempe: Hi, I pushed a fix in the drm-misc-fixes branch 2 months ago, and it's still not present in the drm-misc-next branch. The commit is "23437509a6947 drm/panic: Fix 24bit pixel crossing page boundaries"
08:38emersion: sima: eh, i pushed it to drm-misc-next before you replied. i suppose it's not that of a big deal (it's not a super important bugfix)
08:38emersion: thanks for replying!
08:39sima: emersion, could ask mlankhorst to cherry-pick it over
09:27mlankhorst: I can likely backmerge?
09:35jani: there's a backmerge already by mripard
09:36jani: I know because https://lore.kernel.org/r/20251215092706.3218018-1-jani.nikula@intel.com
09:42jfalempe: Yes thanks, I can see the backmerge now.
15:41Company: Venemo: somewhat heretical question about #5882 - do you think that work is still worthwhile? The gfx8 GPUs are on their way out and it feels to me like there's very few people remaining that use them
15:42Company: 2-3 years ago when I did the original GTK Vulkan port, I knew a few people who used those gpus, but the last one I knew bought a new one last month
15:43Ermine: IIrc RX 470 is gfx8?
15:43MoeIcenowy: Ermine: it is
15:43Venemo: Company: you mean DRM format modifiers? yes, I think it's worth doing. Polaris is still popular according to the Steam survey
15:43MoeIcenowy: GCN4 is just GCN3 refresh, and GCN3 is GFX8
15:44MoeIcenowy: Polaris should still be popular
15:44MoeIcenowy: and even Oland is still frequently used as desktop-only GPU (no gaming, of course, except wine winmine)
15:45Ermine: If you need testing, ping me, since I daily drive this GPU and I won't be bying a new one any time soon
15:45Venemo: soonest I can do anything on this topic is february
15:45MoeIcenowy: BTW I remember ROCm used to recognize Polaris as gfx803
15:45Venemo: thank you Ermine
15:45MoeIcenowy: (before GFX8 support was nuked from ROCm
15:47MoeIcenowy: (I don't know anyone still using gfx7, maybe it's because there's no low profile cards for gfx7
15:47MoeIcenowy: (but for gfx6 there was Oland and for gfx8 there was Polaris12
15:48MoeIcenowy: BTW VK_EXT_image_drm_format_modifier could be useful if experimenting with Zink
15:54Venemo: MoeIcenowy: drm format modifiers are necessary for Zink and for desktops that want to have a Vulkan renderer
16:01glehmann: I think it's worthwhile for the VK ecosystem, ideally every linux driver should support drm format modifiers
16:05Venemo: yeah
16:08MoeIcenowy: Venemo: well yes, I just verified it for trying to implement kmsro with Zink
16:08MoeIcenowy: and found that w/o EXT_image_drm_format_modifier, strides of external buffers cannot be specified
16:08Venemo: yeah
16:08MoeIcenowy: (which prevents GPUs from importing buffers from other devices even if it's promised to be linear
16:10MoeIcenowy: especially it fails here with display controller -- which prevents every my intended use for Zink (running compositors either directly with Vulkan or with Zink
16:20Venemo: MoeIcenowy: correct. you hit the nail on the head
16:23Company: MoeIcenowy: the other problem is GL/Vulkan interop
16:23Company: in application code
16:24Company: because it's easy to make that work with dmabufs
17:03zzyiwei: Looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38270 landed w/o reviews, and the revert from breaking device select: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38953, I wonder under what criteria to revoke dev/project access for ppl doing such <_<
17:12daniels: zzyiwei: revoking that would only be for persistent stuff, not the first mistake
17:35karolherbst: well it was supposedly code that was in production use already, while it would be cool to get reviews the next time it's also not like somebody merged something that never saw a different computer
17:38robclark: meta-comment: would probably be more useful if CI could catch this sort of issue pre-merge
17:40glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14482 not sure if I should tag this as (llm) spam
17:44CounterPillow: Demanding human sacrifices as punishment for good-faith regressions also has a negative impact on the long-term availability of developers who can review QNX merge requests in this case.
18:32zzyiwei: It took me some guts to ask this question since it was hard to bring up. To be clear, I wasn't demanding punishment for this case (I care but also don't care), and was seeking clarifications and more voices. Operating with the best kindness is fine, but meanwhile having some relaxed/tolerant criteria in-place included in the general guidance wouldn't hurt (and saves me some guts).
20:54karolherbst: glehmann: it depends... llm bots are able to find legitimate security issues, but it only really works out if the user absoultely knows what they are doing
20:56karolherbst: but yeah.. the code looks very... useless
20:59dcbaker: gfxstrand: I've got a 25.3 question for you. "pan/bi: Run nir_lower_all_phis_to_scalar() late" applied with a minimal diff, but produces a fairly large set of test failures. Is there anything here that looks obviously out of place to you?
21:00dcbaker: https://gitlab.freedesktop.org/mesa/mesa/-/commit/499cfd9575c69d2e6c93046928da2b3f5d2f2714
21:00dcbaker: You can see the exact issues with the pipelines from the top two commits on the staging/25.3 branch
21:10karolherbst: oh no.. it's a person doing an AI security firm
21:19CounterPillow: let me guess, someone found a backtracking regex in your build system and is now applying for a CVE for it.
22:01pac85: if run and monitor gives me `Error retrying job zink-radv-cezanne 3/4: 403: insufficient_scope` does it mean I didn't give enough permissions to the access token?
22:49pac85: yeah that was it