00:31DavidHeidelberg: eric_engestrom: maybe at least to staging, so people could grab it if they need build 24.1 for some testing purposes?
00:32DavidHeidelberg: 24.0 builds fine on lateat debian unstable, 24.1 fails without this commit, 24.2 builds fine
01:30kisak: DavidHeidelberg: fwiw, it's probably less hassle to download the commit as a .patch and throw it in <build>/debian/patches/name-you-want.patch, and add it to .../debian/patches/series
01:31kisak: less hassle than trying to force an EOL branch to make changes.
01:39DavidHeidelberg: kisak: I don't need it anymore as I patched it locally, it's just it builds without a problem, so if anyone else will need it, he'll have to go trough what I did
12:08mahkoh: If the same dmabuf is used in a vulkan compute or transfer queue and a graphics queue at the same time (but from different processes sharing a dmabuf), can this lead to a GPU reset or context loss?
12:15Company: I always thought that layout transitions can cause issues
12:15Company: which is why I never use dmabufs that I sent to the compositor until the compositor released them
12:16Company: but no idea if that's specced somewhere
12:18Company: I vaguely remember discussing this in the context of using the previous frame as a source for blitting unchanged parts of the current frame
12:18Company: while the previous frame is still being in use by the compositor
12:18Company: and deciding that's probably a bad idea
14:12bl4ckb0ne: is there a way to get more info from vkGetPhysicalDeviceImageFormatProperties2 when VK_ERROR_FORMAT_NOT_SUPPORTED is returned?
14:14zmike: gdb the driver
14:16bl4ckb0ne:buckles up
14:18bl4ckb0ne: ofc its android, it's going to be a nightmare
15:51bl4ckb0ne: found it, VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT was the issue
15:54bl4ckb0ne: because it was a color format
16:22mahkoh: What are the usecases of the gbm_surface API? I read that mutter uses it but I don't understand what it offers that the gbm_bo API + dmabuf export/import doesn't.
16:23daniels: works with EGLSurface (mostly convenience), also gbm_bo as a render target historically had issues with some drivers
16:28emersion: i use gbm_bo exclusively and it works well
16:28mahkoh: Same, that's why I was wondering why mutter used it while reading https://gitlab.gnome.org/GNOME/mutter/-/issues/3461#note_2235674
16:29daniels: yeah, hence ‘historically’ - it now works well across the board
16:30mahkoh: "It existed before opengl gained support for importing dmabufs" was my first guess.
16:32daniels: more about not having a SwapBuffers-like barrier for FBOs so drivers that need shadow resources or decompression etc know when they need to do that
16:33jadahl: mahkoh: there is also 'EGL_KHR_partial_update' which i'm not sure you can do without EGLSurface
16:34jadahl: i.e. 'eglSetDamageRegionKHR()'
16:35emersion: for that there is https://github.com/KhronosGroup/OpenGL-Registry/issues/547
16:35jadahl: seems I was subscribed to that already :o
16:40mahkoh: daniels: interesting, I hadn't considered how this worked in opengl (and so far it has "just worked")
18:08robclark: looks like mali-450 runners are down? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/64857354
18:14robclark: cwabbott: I think you can revert b339c525f449f19f6515201509d8a7455d239195
18:16daniels: cwabbott: yeah, pls do
18:34daniels: austriancoder: perhaps mute :)
18:35austriancoder: daniels: 🤣
18:36daniels: don't forget to unmute either :P
18:38daniels: austriancoder: we can hear you but you've frozen
18:40daniels: austriancoder: ericsmith wanted to talk a little about integer promotion
19:21bl4ckb0ne: what could cause `lseek(dma_buf, 0, SEEK_END);` to return 0?
19:29robclark: daniels: hmm, it appears not to have been so simple.. https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/1286639
19:30daniels: separate NR
19:30daniels: don’t combine disables with any other changes
19:32robclark: ok, will try that.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31580
19:39cwabbott: 🙏