05:15mangodev: is it known that https://gitlab.freedesktop.org/mesa/mesa/-/commit/58f8143da3ef5ba6afa8d55e4ccb4b08014ab9e8 causes logspam for drivers other than etnaviv?
07:03austriancoder: mangodev: no .. tell me more
07:06mangodev: austriancoder: lemme open journalctl rq to see the exact error
07:06mangodev: it was complaining about an invalid color format
07:06mangodev: found it
07:06mangodev: from discord, interestingly enough; electron doesn't seem to like it
07:07mangodev: from shared_image_interface_proxy.cc, gpu_channel.cc, and gbm_pixmap_wayland.cc
07:07mangodev: seems to be a loop of
07:07mangodev: 'ERROR:shared_image_interface_proxy.cc(134)] Buffer handle is null. Not creating a mailbox from it.'
07:08mangodev: 'ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE'
07:08mangodev: and
07:08mangodev: 'ERROR:gpu_channel.cc(503)] Buffer Handle is null.'
07:08mangodev: and it repeats… ***every frame***
07:09austriancoder: mangodev: and if you revert that commit, everything is fine?
07:10mangodev: when i built my drivers yesterday (before the commit), everything was fine yes
07:30austriancoder: mangodev: I do not see such errors with discord and mesa main. the nightly ci run seems also to be fine (which happened after that MR was merged).
07:30austriancoder: mangodev: it would be really helpful if you can update to mesa main, revert that commit and check if the error is still here
07:32mangodev: austriancoder: i can maybe try tomorrow, but i do not have a test machine, my daily driver is my test bench
07:44Hazematman: mangodev you can run mesa without installing using the meson devenv commands so you don't have to worry about it messing with other stuff on your daily driver https://docs.mesa3d.org/install.html#running-against-a-local-build-easy-way 07:47sima: jani, airlied I guess dotfiles too?
07:48jani: sima: airlied: been looking into it. the .cmd files are indeed .foo.cmd, so I'll try to do the same
07:50jljusten: eric_engestrom: We talked about 0e648a238e2 on March 20. Should I be seeing it on staging/25.0 yet? btw, d3ec4670317 is similar, but I only tagged it for 25.0, since I guess we are probably done with 24.3 now. ?
07:51sima: jani, also I guess cc jgg, since he seems interested in this too
07:51jani: jason gunthorpe?
07:51sima: yeah
07:51sima: not trying to enable anything he has, just for support
07:51sima: and then leaving roll-out to other places up to him
07:52jljusten: eric_engestrom: if we do make another 24.3 release, I guess it would be nice to include d3ec4670317 as well.
08:02jani: sima: there actually still is a header test for installed kernel headers
08:02jani: sima: I thought that's what he was referring to though I didn't look it up
08:03sima: jani, is that doing dotfiles or also spam?
08:03sima: and yeah could be jgg is just confused
08:12jani: sima: with HEADERS_INSTALL=y and UAPI_HEADER_TEST=y you also get "disgusting turds" with exactly the same naming, but they're under usr/include so linus hasn't noticed or doesn't care
08:13sima: hm I guess we should rename those too in the same series for consistency at least?
08:14jani: sima: I'm struggling a bit because the make rule is "$(obj)/%.hdrtest: $(src)/%.h FORCE" and that would be fine if we recursed to every single directory with makefiles
08:14sima: but yeah maybe linus doesn't care because it's in a separate dir
08:15jani: can't do that because it would be a shitload of new makefiles just for this
08:16jani: instead we use find -name *.h, and then the % pattern part of $(obj)/%.hdrtest also contains the subdirectory, not just the basename
08:16sima: I think my make skills are a lot more basic than yours ...
08:17jani: :)
08:17jani: 5000 patch series to convert the kernel to meson and ninja
08:17sima: there's no way to split this into basename and dirname?
08:17sima: was about to suggest that :-P
08:18jani: I find there are very few things that you can't do in make. it's just that they are cumbersome and obscure and nobody fucking knows how to do them
08:20jani: Kbuild.include actually has this helper:
08:20jani: # Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
08:20jani: dot-target = $(dir $@).$(notdir $@)
08:20jani: but that doesn't help with the pattern rule
08:27sima: generate makefiles?
08:27sima:has no taste
08:44Company: I think I did a very dumb thing
08:44Company: and that's writing tests for all the weird YUV formats in Vulkan, to copy them into and out of VkImages
08:46Company: and AMD loses the 3rd plane, llvmpipe swaps planes when there's a non-identity swizzle and then the copying back out is wrong
08:46Company: it seems nobody uses those so they're not really tested?
08:58Company: otoh, maybe I'm doing sth wrong because the validation layers explode with that code, too
08:58Company: does the cts have tests for that stuff?
09:02Hazematman: Company: did you try the ycbcr CTS tests? https://github.com/KhronosGroup/VK-GL-CTS/blob/main/external/vulkancts/mustpass/main/vk-default/ycbcr.txt 09:03Company: I still have a hard time finding my way around, so no
09:04Hazematman: There is a bunch of ycbcr related tests in the `dEQP-VK.ycbcr.*` namespace. You can find the code for them here https://github.com/KhronosGroup/VK-GL-CTS/tree/main/external/vulkancts/modules/vulkan/ycbcr 09:04Hazematman: I'm not sure if there are testing doing exactly what you're doing, but maybe you can search through there
09:07Company: that looks very extensive at least
09:21Company: looks like it's mainly llvmpipe that is busted. And that's mostly just because it does report its supported features wrong
09:21Company: only other busted thing seems to be my code
12:13valentine: mupuf: In case you'd like to try gfx-ci/linux 6.14 on sm8650-hdk: https://gitlab.freedesktop.org/Valentine/linux/-/commits/hdk-dtb 12:14valentine: kernel image and dtb in the job logs - it works on our sm8350-hdks, but might be missing some configs for you
12:14mupuf: thanks
12:15mupuf: probably does, but I can try to port the required stuff
14:51zmike: jenatali: how are you coming with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34054 15:11jenatali: zmike: Haven't gotten to it yet, I'm in the middle of implementing shader model 6.9 for WARP. I should be able to take a look this week
15:11zmike: great
15:11zmike: thanks
15:22ity: Is there an IRC channel for llvmpipe ? Or should I shoot my questions here ?
15:27ity: (My specific question is asking if there's a way to use llvmpipe as a library & extract the framebuffer from it while running an app without a display server)
15:28jenatali: You should be able to do that with EGL
15:31mattst88: yeah, that sounds just like EGL_KHR_surfaceless_context or whatever the name is
15:34ity: Oh hmm (am I overcomplicating it)
15:36ity: Hmm, I read the EXT and Ia m not sure I understand how I'd use it for this (https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_surfaceless_context.txt) 15:37mattst88: you just make a standard opengl application, creating its context with EGL and no display surface
15:38mattst88: then you can create framebuffer/renderbuffer objects, render to them, read them back, etc
15:39ity: Ah hmm
15:39ity: Ig that could work
15:39ity: Thanks !
15:40mattst88: yw :)
15:54ity: Hmm, I need a display for EGL to succeed initializing, is there a similar EXT for that ?
15:56daniels: EGL_MESA_platform_surfaceless
16:07ity: OH thanks!
16:25eric_engestrom: jljusten: for 24.3, I don't think there will be another one (/cc dcbaker), so I'm dropping it from the calendar (mesa!34325)
16:26eric_engestrom: jljusten: for 0e648a238e2, it will be in the next 25.0, but I haven't managed to get the CI to fully work on the release branch yet, so all the backport commits are queued locally (62 of them as of friday) until I get CI working first, and then I'll do a CI run with all of these
16:28dcbaker: eric_engestrom, jljusten: I had more patches pulled into the 24.3 branch locally, but at this point 25.0 is out so it seems... not that useful? unless there's a pressing reason to make another 24.3 release (like a major issue in an LTO distro) I'd be just as happy to drop it from teh calendar
16:29jljusten: eric_engestrom: are you trying to get CI stable before adding any more patches, or d3ec4670317 could make it into the next 25.0 release?
16:31eric_engestrom: both :)
16:31eric_engestrom: right now I don't have anything in staging/25.0 other than trying to get ci working (and a bugfix for the backport tool itself)
16:32eric_engestrom: once CI is working, I'll push the 62 backports I have queued, including yours
16:32eric_engestrom: and I'm not going to make a release until I have the "real" content to release :)
16:42jljusten: dcbaker: Yeah, I guess you are right. We should not worry about another 24.3 release unless we find a distro that's going to stick with it rather than going to 25.0.