05:08mahkoh: Is it correct that when importing pre-initialized dmabuf images into vulkan, the initial layout should be VK_IMAGE_LAYOUT_UNDEFINED but the transitions from the QUEUE_FAMILY_FOREIGN into one of the device queues should use VK_IMAGE_LAYOUT_GENERAL as the source layout?
05:18mahkoh: I've seen that zink uses PREINITIALIZED but the driver implementations contain comments that PREINITIALIZED=UNDEFINED for anything other than host-accessible, linear images.
05:18mahkoh: And using UNDEFINED seems wrong.
05:35airlied: PREINITIALIZED is correct afaik
05:43mahkoh: I mean, using GENERAL seems to work de facto. It violates the spec but so would using PREINITIALIZED. You're not allowed to use PREINITIALIZED as the initialLayout for dmabuf images. The spec requires UNDEFINED.
05:44mahkoh: And ImageMemoryBarrier requires oldLayout to be the initialLayout or UNDEFINED. So you cannot use PREINITIALIZED there if you create the image with UNDEFINED.
05:44mahkoh: zink currently does initial=UNDEFINED and old=PREINITIALIZED
05:45airlied: the problem from memory with UNDEFINED is that UNDEFINED->GENERAL can cause problems
05:45airlied: if there is already data
05:47mahkoh: I wonder why the spec disallows initial=PREINITIALIZED for images with VkExternalMemoryImageCreateInfo.
05:49airlied: looks like UNDEFINE
05:49airlied: looks like UNDEFINED is what you should use
05:51mahkoh: That's what the spec says but then you also have to use UNDEFINED as the oldLayout in the ImageMemoryBarrier because of https://docs.vulkan.org/refpages/latest/refpages/source/VkImageMemoryBarrier.html#VUID-VkImageMemoryBarrier-oldLayout-01197 05:51mahkoh: unless there is some other way to change the current layout of the subresource
05:53mahkoh: Everyone seems to just ignore that VUID and use GENERAL or PREINITIALIZED instead.
05:53mahkoh: VVL doesn't care either.
09:28glehmann: mahkoh: there were long discussions about this, and I think GENERAL for the acquire barrier was effectively agreed on
09:28glehmann: I don't think the initial layout matters
10:29mahkoh: I've opened https://github.com/KhronosGroup/Vulkan-Docs/issues/2652 to ask for clarification
10:45dj-death: mahkoh: using VK_IMAGE_LAYOUT_UNDEFINED for imports will break some intel platforms
10:45dj-death: mahkoh: same for queue transitions (althought those devices usually don't have more than 1 queue)
10:46dj-death: Furmark is one of those broken apps that even does a UNDEFINED to SRC_PRESENT
10:46dj-death: which wipes the compression data before presentation
10:58Company: mahkoh: as a datapoint, GTK has been using GENERAL for a while now
12:47dolphin: airlied, sima: Will send a singular drm-intel-gt-next PR next week, we're currently at 3 patches.
15:31dj-death: eric_engestrom: do I need to wait for the release maintainer to merge a change to 25.3? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39209 17:07eric_engestrom: dj-death: dcbaker manages 25.3, so that's who you want to ping on the MR, but yeah generally it's best if the release manager does the merge as they might have other changes in parallel and since it's a rebasing branch, gitlab doesn't handle it very well, so the simplest is for the release manager to decide when is a good time to merge :)
17:08dcbaker: dj-death: I sent that to marge.
17:08dj-death: dcbaker: thanks!
17:08dcbaker: eric_engestrom: thanks for the ping :)
17:09eric_engestrom: :)
17:35etno: Hello! I am trying to configure mesa to perform swrast via GLX (with direct rendering) on a platform lacking DRM. Is this achievable and, if so, which config flags should I set ?
17:39etno: Current attempt is with : glx-direct=true glx=xlib osmesa=true glvnd=false gallium-drivers=['swrast']
17:40etno: But I am not even sure I am headed in a reasonable direction 😅
17:58MrCooper: etno: don't need osmesa, and gallium-drivers takes llvmpipe / softpipe instead of swrast, other than that looks like a good start at least
18:15etno: MrCooper: thanks a lot, I will persevere a bit based on your hints
20:02alyssa:wonders if she made the wrong call for unified atomics back in 2023
20:02alyssa: and if the _swap intrinsics shouldn't exist in favour of just vec2 data args..
20:03alyssa: would probably be a lot more convenient most places :/