03:32mareko: karolherbst: any alignment requirements?
04:18zzyiwei: Can anyone help review this win32 wsi fix? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40557 This is to respect acquire timeout on non-DXGI sw wsi path. CI is passing and the fix has been verified by issue reporter already.
05:36RAOF: Has anyone run into a weird problem when importing (linear) dmabufs from i915 to nvidia have the wrong stride unless the width is a multiple of 8?
05:55zzyiwei: RAOF: this can be similar https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/651. In our case, the image stride in the prime blit buffer has to be aligned no more than 32bytes, otherwise distorted. The default 256 alignment isn't respected.
05:56zzyiwei: Here's the NV side ticket filed by ifaigios: https://forums.developer.nvidia.com/t/egl-import-via-egl-ext-image-dma-buf-import-modifiers-ignores-explicit-stride-causes-image-distortion-in-virtio-gpu-venus/364360
05:57RAOF: Interestingly this works for importing from amdgpu, but that _might_ just be because amdgpu allocates with a sufficiently aligned stride anyway?
06:42MoeIcenowy: https://gitlab.freedesktop.org/imagination/mesa/-/issues/18 when testing Zink on PowerVR, many ES CTS failures disappeared when I set MESA_GLES_VERSION_OVERRIDE=3.0
06:43MoeIcenowy: should I fix these situations in state tracker / Zink ?
08:28MrCooper: RAOF: yeah, amdgpu aligns stride to a multiple of 256 bytes, Intel iGPUs have much lower constraints
10:23mripard: tzimmermann: I'd like to merge https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-0-f3935f6db579@kernel.org today, ok for you?
10:24tzimmermann: mripard, sure. np
14:39karolherbst: mareko: yeah, must be aligned to the pattern size
14:39karolherbst: the GPU memory I mean
14:40karolherbst: so the offset within the buffer should be aligned to the buffer
14:40karolherbst: *aligned to pattern size
15:05alyssa: dschuermann: are you planning on a follow up ACO MR to delete continue support?
15:06alyssa: Like I .. think we can delete a pile of code from every backend now
15:06alyssa: but I don't want to be the first in case I misunderstand the long term vision here
15:08alyssa: I assume we are closing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33039 now
15:08alyssa: ?
15:10dj-death: what is going on with some of the trace replay?
15:10dj-death: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/96013524/artifacts/results/summary/problems.html
15:10dj-death: the rendered images don't even have the same size
15:11zmike: that was brought up in #freedesktop and tl;dr idk
15:59dj-death: zmike: yeah... I think can see what is going on
15:59dj-death: zmike: swapchains created from the GL thread
16:01dj-death: zmike: on a renderpass begin
18:35mareko: karolherbst: that will need a brand new compute shader, just note that the compute shader should clear 16B per invocation, otherwise it won't perform well
18:37karolherbst: mareko: okay.. I was considering emulating it in rusticl with a shader tbh, but it's going to be tricky to do it the optimal way .. but it's also soo rare for it to be used this way that it might not matter much
18:38karolherbst: but yeah.. shouldn't be too difficult to emulate properly
18:38karolherbst: I wanted to have something for all the drivers that do clears on the CPU anyway
18:39mareko: it's very simple actually, just bind an SSBO, load 16B of the clear value for the invocation, and store it
18:40mareko: that's only for clear values >= 32B; for smaller clear values, radeonsi shaders are difficult to beat
18:40karolherbst: ohh yeah, the shader itself isn't the issue. I just have 0 infrastructure in place to create internal shaders
18:41karolherbst: so most of the work would be on creating that infrastructure anyway
18:42karolherbst: anyway yeah, I can use it only for bigger clears for now and consider using it for smaller ones for all the drivers using "u_default_clear_buffer" later once everything is in place
18:43karolherbst: actually.. that might fix some synchronization issues I was seeing with more aggressive threading... mhh
19:49glehmann: interesting how intel has 2 backend compilers but 5 compiler related MR labels
19:56Sachiel: we should clean those up
19:57dj-death: we should just add one to rule them all
19:57Sachiel: there is intel-compiler already, what would you add?
19:58Sachiel: one-intel? Marketing would like it
20:00dj-death: not sure why -fs & -vec4 still exist
20:30mattst88: Sachiel: lol
21:30dakr: alarumbe: Sorry, lots of stuff on my TODO list, I will go over it tomorrow.
22:31lumag: narmstrong: would woul be the best way to merge https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-0-ff6afc904115@pm.me ?
22:31lumag: Ideally I'd not like to span it over two cycles
22:32lumag: mripard, mlankhorst: would it be okay to merge MIPI_DSI_FMT_RGB101010 addition through drm/msm?
22:33lumag: narmstrong: would it be fine with you to have a warning in meson code until you have a chance to land the patch? or would you prefer some other way to handle it?
22:33lumag: another approach would be to have a immutable tag for the first patch, which then can be merged both in drm-misc-next and msm-next
23:08bitblt: Hello! I recently changed to using systemd-based initramfs instead of busybox-based initramfs with mkinitcpio. I noticed that the systemd hook parallelizes some stuff and performs the mode setting step a bit later, just before the step that asks me for my luks password. This mode setting, results in the same exact resolution (+ font size) but has a somewhat annoying side effect that it creates a pretty big empty space between the previous l
23:08bitblt: ogs and the logs that prompt for my luks password. When I used the busybox-based initramfs, the kms step happened very early just before the luks prompt, so it didn't mess/disrupt any of the boot logs later. I found out about the seamless amdgpu kernel param that doesn't seem to do anything for my Ryzen 7 5800H / Vega 8 iGPU in regards of the aforementioned behavior. Any idea on how/if I can make my boot have as few modesettings as possible
23:08bitblt: with amdgpu?