10:30 mahkoh: On Intel and AMD iGPUs, is there a significant performance overhead when sampling linear textures without scaling or rotation?
21:07 cmarcelo: if there are people using the `jj` vcs with mesa repository: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37704
21:19 trofi: I have an ADM GFX8 video card "lspci names it as Lexa XT [Radeon PRO WX 2100]". I want to figure out if this card supports DRM_FORMAT_MOD_LINEAR. wayland-info with zwp_linux_dmabuf_v1 v4 on sway claims it does, zwp_linux_dmabuf_v1 v3 claims it does not and supports only DRM_FORMAT_MOD_INVALID. Various projects like chromium and wine-wayland had to adapt to fix things for this card.
21:20 trofi: I wonder if you can help me debug and figure out if this card is expected to support DRM_FORMAT_MOD_LINEAR and there the bug lies in (false?) advertising DRM_FORMAT_MOD_LINEAR support
21:24 emersion: it's kind of a grey area
21:24 emersion: advertising LINEAR is not wrong, not advertising it is also not wrong
21:25 trofi: Bit of chromium workaround if it helps: https://issues.chromium.org/issues/446395287#comment3
21:38 trofi: emersion: what should clients normally do to find out actually supported format and pass somethng reasonable to gbm_surface_create() / gbm_surface_create_with_modifiers()? trial and fallback?
21:50 emersion: just because the compositor supports some modifiers, doesn't mean the GBM implementation used by the client supports them
21:52 emersion: the client is expected to first try with gbm_bo_create_with_modifiers(), then fallback to gbm_bo_create() if the compositor has advertised INVALID
21:53 emersion: GBM_BO_USE_LINEAR with gbm_bo_create() has the same effect as a {LINEAR} modifier list with gbm_bo_create_with_modifiers()
22:00 trofi: Thank you!
22:01 emersion: i've added this as a comment
22:03 trofi: Perfect! I suspect I might have to point to it for other projects as well.
22:04 emersion: here is a possible implementation, for reference: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/d8fb7adcf041af7e958804b77c9a6669fbff4efd/render/allocator/gbm.c#L71
22:05 emersion: with a note that this hardcodes GBM_BO_USE_SCANOUT because it's a compositor, usually you would want to conditionally set this flag depending on the linux-dmabuf tranche flags
22:07 trofi: *nod*
22:12 emersion: (gbm_surface_create_with_modifiers() allows passing flags)
22:12 emersion: err
22:12 emersion: (gbm_surface_create_with_modifiers2() allows passing flags)
23:00 lumag: robclark: I tried running other CL-GL interop examples and got the same error as you got with the CL CTS. I think it's an issue somewhere in Mesa / RustiCL (or fdo?).
23:01 lumag: karolherbst: are there any known issues with CL-GL interop in Mesa? (we are getting MESA: error: flush_submit_list:135: submit failed: -24 (Too many open files))
23:02 karolherbst: lumag: mhh.. guess too many open fds is an issue
23:02 karolherbst: should file a bug with the details
23:03 robclark: yeah, I saw the too many fd issue too.. looks like a pipe_fence leak.. asan says same issue w/ zink.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37696
23:03 robclark: pls cc me on issue
23:04 robclark: karolherbst: fwiw the leaked fences seem to be coming from the gl pipe_context, if that helps
23:06 karolherbst: uhhh... maybe?