07:38mripard: narmstrong: stop replying to him, you've said what you wanted to see fixed, it's their responsibility now
07:43mripard: (I'm not sure if Dmitry is around)
08:13narmstrong: mripard: yep, I planned to not reply anymore !
09:24Company: so, this might be a very dumb question, but:
09:25Company: how do I get the number of planes for a dmabuf vkImage?
09:25Company: do I need to go and ask the physical device?
09:26Company: and 2nd question: Once I know the number of planes, how do I get the fds? Because vkGetMemoryFdKHR() only gives me one fd - or can I assume that it's the same fd for every plane?
09:30gawin: How to get intel_stub_gpu for shader-db?
09:31gawin: (seems undocumented)
09:43Company: that seems to indeed be how it's supposed to work
09:48emersion: depends if DISJOINT or not Company
09:49Company: well, that's another fun thing I can't figure out
09:50Company: because I handed a bunch of modiferes to vkCreateImage() and then it went and picked one and created the image
09:50Company: but considering that I only vkAllocateMemory() once with this approach, disjoint is probably not gonna happen
09:51Company: but then, I'm just following the Export stuff in https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_image_drm_format_modifier.html for now, maybe that's missing some fun stuff
09:53Company: lucky for me, AMD picks a 2-plane format by default, so I get to test my code immediately
09:55Company: and on top of that, I think I know now why qemu-dbus or libmks is broken - because it naively assumes 1 plane
10:05dj-death: gawin: it's part of mesa
10:05dj-death: gawin: compile it with -Dtools=intel
10:05dj-death: gawin: should get installed
10:06gawin: thx
10:08dj-death: Company: memory is disjoint from image
10:09dj-death: Company: you could bind the same memory to different plane with an offset
10:09Company: yeah - that's why I was wondering about querying fds per-plane
10:09dj-death: since you're in charge of binding the memory to the image, you know where the fd is
10:10dj-death: just get it from the VkDeviceMemory object
10:10Company: that only works as long as I have only one memory object
10:10Company: once things get disjoint, I need to know which memory object belongs to which plane
10:11dj-death: yeah
10:11dj-death: usally they come in order ;)
10:11Company: I'm not even sure how that would work, because I get to create the DeviceMemory
10:14dj-death: I just don't get what your problem is :/
10:15Company: currently I'm wondering how I would go about creating disjoint vkImages
10:15dj-death: you need the right format first
10:15Company: because vkGetImageMemoryRequirements2() has no way to tell me that I would need a 2nd DeviceMemory
10:16dj-death: only some formats support disjoint
10:16Company: right
10:16Company: and only some GPUs support disjoint
10:17dj-death: there is a VkImagePlaneMemoryRequirementsInfo that you can chain in VkImageMemoryRequirementsInfo2
10:17dj-death: and specify the aspect plane in there
10:17dj-death: VK_IMAGE_ASPECT_MEMORY_PLANE_(0|1|2)_BIT_EXT
10:17Company: that was what I was missing
10:17dj-death: than you use the same aspect plane for the bind operation
10:18dj-death: s/than/then/
10:18Company: that was missing from https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkMemoryRequirements2.html
10:18dj-death: not super intuitive
10:18Company: "pNext must be NULL or a pointer to a valid instance of VkMemoryDedicatedRequirements"
10:18Company: it should be there
10:18dj-death: yeah because VK_IMAGE_ASPECT_MEMORY_PLANE_(0|1|2)_BIT_EXT is part of the VK_EXT_image_drm_format_modifier I think
10:18Company: nah, that's usually in there
10:19Company: it's how I found the dmabuf-specific structs to chain into all the other calls
10:19dj-death: you might be looking at the spec not compiled with all the extensions
10:19Company: see the link - it's the variant with extensions
10:19dj-death: yeah it should be in there
10:19dj-death: maybe something missing in the spec
10:20dj-death: Company: ah no
10:20dj-death: Company: that's the output structure
10:20dj-death: Company: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageMemoryRequirementsInfo2.html
10:20dj-death: is the one you want
10:21Company: ohhhh
10:21Company: so I have to query the memory requirements for each plane
10:21Company: right, makes sense
10:23Company: but because I don't set the disjoint flag on vkCreateImage() (yet?), I don't need to do that dance
10:24dj-death: yeah
10:24dj-death: it'll give out an aggregated size
10:24Company: yeah, and then I have to query the subresourcelayout
10:25Company: when I export the dmabuf
10:25Company: I understand how it works now
10:25Company: also: it works now
10:26Company: I render with vulkan, export a dmabuf, import it via eglCreateImage() and then render it with GL
11:07dumbbell: Hi! I'm trying to understand how fbdev and drm_fb_helper wrork w.r.t. panic handling. I see the fb_debug_{enter,leave} callbacks but it seems the i915 driver doesn't support this code path (mode_set->crtc->helper_private is NULL in drm_fb_helper_debug_enter())
11:07dumbbell: For the context, I'm a FreeBSD contributor and I'm working on porting the DRM drivers from Linux 5.17. In the process, I'm revisiting how our console/framebuffer integrates with DRM and wanted to use the fbdev callbacks exposed by drm_fb_helpêr.
11:27pcercuei: dumbbell: is it actually NULL at runtime?
11:29dumbbell: pcercuei: Yes, it panics on the second line of this code:
11:29dumbbell: funcs = mode_set->crtc->helper_private;
11:29dumbbell: if (funcs->mode_set_base_atomic == NULL)
11:29dumbbell: (funcs is NULL)
11:30pcercuei: Yeah at the very least it should check that it's non-NULL here. I do wonder however why it's NULL.
11:31kusma: hmm
11:33kusma: How do we deal with developer access for repos under the Mesa namespace that aren't the Mesa repo itself? It seems we used to give group-level permissions when they'd "proven themselves" in the Mesa repo, and that'd give them permissions for the others. But looking at the members list, it kinda looks like the trend has become to only give repo-level access... And while that might not be bad in itself, I'm a bit worried that we'll get less and less
11:33kusma: people with commit access to repos like mesa/demos and mesa/piglit... Should we start doing similar per-repo permissions for those repos as well, or just ask "somewhere" to get users "upgraded" to group-level developers?
11:34dumbbell: pcercuei: I suppose there is an alternative code path for drivers supporting atomic modesetting because that loop in drm_fb_helper_debug_enter() will skip them, but I can't find it
11:41mareko: gk20a CI is down: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/51980673
11:45pcercuei: dumbbell: I'll leave it to others, I don't really know how that code works (or what it's for)
11:46dumbbell: pcercuei: Thanks for your help so far :)
11:54javierm: sima: is https://patchwork.kernel.org/project/dri-devel/patch/20231123221315.3579454-5-javierm@redhat.com/ what you had in mind?
11:55daniels: mareko: anholt isn't here, so please just include a commit whcih `git mv .ci-farms{,-disabled}/anholt` per https://docs.mesa3d.org/ci/#farm-management
11:58DavidHeidelberg: it should be standalone MR, I'll send it
12:00daniels: yes sorry, failing at doing n>1 things at once
14:03sima: javierm, r-b: me
14:04sima: like I'm not sure it's super-clear, but then I'm not sure I'm super clear on this, but it does at least explain it all I think
14:07javierm: sima: Ok, thanks for the proof reading. And yeah, we can always make it more clear as follow-up
14:08javierm: sima: I'll merge then the series. Appreciate your help on this
19:16Venemo: Lynne: let me know if you still have issues with the multiplanar image copies. sorry for getting back to you so late