08:03phasta: tzimmermann, morning. are you in charge of Bochs?
08:03phasta: https://lore.kernel.org/all/20241017125145.34729-2-pstanner@redhat.com/
08:04tzimmermann: phasta, ha! no i sent that patch and i now i wait for a review
08:05phasta: Ahm? ^^ I'm pretty sure I'm the one who sent it
08:16tzimmermann: phasta, oh. i just miss interpreted
08:16tzimmermann: :D
08:16tzimmermann: i'll have a look
08:16tzimmermann: sorry, -ECOFFEE
08:25tzimmermann: looks like it's been fixed already
08:27phasta: where? on a drm-branch? On 6.12 it's still the old thing
08:45phasta: ah. Got it
08:56phasta: In case someone is bored, the GPU scheduler docu patch could maybe make use of a review
08:56phasta: https://lore.kernel.org/all/20241115103548.90605-2-pstanner@redhat.com/
09:12tzimmermann: phasta, drm-misc-next at least
09:31Ermine: more docs are always needed
11:48Venemo: melissawen: good afternoon, can we talk about this issue? https://gitlab.freedesktop.org/drm/amd/-/issues/3693 I've just tried Cosmic and the issue is very very easy to reproduce
11:53Venemo: I don't really understand the response from the AMD dev. there is clearly an out of bounds array access which is obviously not fixed in the patch
11:54Venemo: why would they want to allocate an array of size 3 when there really can be 6 planes?
12:12colinmarc: @_oftc_nowrep:matrix.org https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31418 broke my app on both h264 and h265, any idea what I might be doing wrong? nothing is jumping out at me
12:13colinmarc: I'm getting black output in the encode textures, no validation failures or anything else interesting
12:14colinmarc: I did have a lazy assertion, but I already fixed it (https://github.com/colinmarc/magic-mirror/commit/4f5b34931fc01f1d55e3975ed27355a3e376f067)
12:58melissawen: Venemo, hey, I talked to AMD folks about this issue at XDC.
12:58melissawen: AFAIK, surface != planes, so dcn hw supports up to 4 surfaces, even if it can have up to 6 planes
12:59melissawen: but this mismatch is spread throughtout the driver code
13:00melissawen: and they need to untangle the issue before changing to 4, as the issue is also part of the DC code and causing regression in other platforms
13:02melissawen: I see the mismatch in three definitions: MAX_SURFACES, MAX_SURFACE_NUM and MAX_PLANES
13:02melissawen: it's a mess
13:05melissawen: the issue was uncovered by the cursor overlay mode.. and they are trying to prevent more than 4 planes first, meanwhile they untangle the whole thing
13:11melissawen: we have discussed these points here: https://lore.kernel.org/amd-gfx/20241025193727.765195-2-zaeem.mohamed@amd.com/t/#u
13:45Venemo: I see, thanks
17:28dcbaker: tarceri_: 44de5f1c46 "glsl: Move ForceGLSLAbsSqrt handling to glsl-to-nir." is getting nominated as a revert, but it doesn't apply cleanly and doesn't look relevant to 24.3, do you want to backport that, or is it cool if I just drop it?