01:19 ezzieyguywuf: I have compiled mesa locally per https://docs.mesa3d.org/meson.html#installation-location, and (attempted to) included llvmpipe per https://docs.mesa3d.org/drivers/llvmpipe.html#building . I'm unsure how to use this local llvmpipe though
01:20 ezzieyguywuf: I tried LD_LIBRARY_PATH=${PWD}/build/install/lib/x86_64-linux-gnu/ vulkaninfo but this still just shows my system-wide llvmpipe
01:20 ezzieyguywuf: I thought about using VK_DRIVER_FILES but I'm not sure which icd file is appropriate
01:21 ezzieyguywuf: I tried VK_DRIVER_FILES=${PWD}/build/install/share/vulkan/icd.d/lvp_icd.x86_64.json but again this seems to return my system-wide llvmpipe
01:23 airlied: run meson devenv
01:23 airlied: that is the right json file for lavapipe
01:23 airlied: maybe try VK_ICD_FILENAMES
01:24 pendingchaos: "meson devenv -C builddir command" should work
01:24 pendingchaos: lvp_icd.x86_64.json might have an absolute path to the shared object in the install directory, which would require running ninja install first
01:25 ezzieyguywuf: also though I may be looking at the wrong part of vulkaninfo, I thought "GPU id : 0 (llvmpipe (LLVM 19.1.7, 256 bits))" meant "mesa 19.1.7" but I don't think that's right
01:26 pendingchaos: no, that's the llvm version
01:26 pendingchaos: search for "driverVersion" in the output
01:26 ezzieyguywuf: b/c I also see " driverInfo = Mesa 25.1.0-devel (git-3c0e0c3d04) (LLVM 19.1.7)" elsewhere
01:27 ezzieyguywuf: that's def newer than my system version
01:27 ezzieyguywuf: > run meson devenv < do I still need to do this? what does this accomplish?
01:29 pendingchaos: runs a command with the VK_DRIVER_FILES environment variables
01:29 pendingchaos: it works for GL too and you might find it more convenient to use than the environment variables, with less typing and no ninja install step needed
01:29 ezzieyguywuf: gotcha
01:32 ezzieyguywuf: so I'm happy with how things look with this local build, is it possible to install it alongside my system-wide mesa? e.g. my specify --prefix to /usr/local or smthn?
01:38 pendingchaos: for vulkan, it should pick that up without any env vars needed and both will be listed in vulkaninfo, but might order it before the system-wide mesa: https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderDriverInterface.md#driver-discovery-on-linux
01:38 pendingchaos: not sure how it works for other apis
01:40 ezzieyguywuf: > but might order it before < this is fine, I want to add logic to my renderer anyways to pick the gpu/driver with the right features
01:40 ezzieyguywuf: thanks for the help
03:38 tarceri: Anyone around to ack this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34171
03:39 tarceri: Its blocked a bunch of MRs from landing today already
03:42 airlied: tarceri: rb sent
03:44 tarceri: airlied: thanks
08:07 MrCooper: is HDR supposed to work via non-atomic KMS, specifically the Colorspace & HDR_OUTPUT_METADATA properties?
09:30 tzimmermann: javierm, no comments on the rest of the sysfb series?
09:34 javierm: tzimmermann: sorry, I couldn't finish but I plan to continue later today or tomorrow morning
09:34 tzimmermann: ok
09:57 dj-death: alyssa: so just FYI, dynamically uniform is less strong that what the divergence analysis gives
10:04 glehmann: how?
10:06 glehmann: I could only see that happening if you have invocations for different draws in one subgroup. If all invocations are from one subgroup, dynamically uniform values will always be not divergent
10:06 tzimmermann: jfalempe, thanks for the ast review. the draw functions and the format helpers have common code for converting pixel formats. i have a few patches to share the per-pixel functions. i'll post em today or tomorrow
10:07 glehmann: of course it's possible that divergence analysis can't prove that a value is not divergent, but for things like push constant loads you would typically solve that by forcing the array index to be uniform in the backend isel
10:09 jfalempe: tzimmermann: ah thanks, I have this on my todo-list for quite some time ;)
10:09 tzimmermann: it's just the start
13:32 lumag: jani, I'd like to push out https://lore.kernel.org/dri-devel/20250324-drm-rework-dpcd-access-v4-0-e80ff89593df@oss.qualcomm.com/. The CI on Xe doesn't show any issues and i915 seems to be unrelated. Are you okay with that?
13:36 alyssa: dj-death: uh?
13:44 jani: lumag: make it so
15:26 bbrezillon: dj-death: When you have time, do you think you could help me with this https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32540#note_2817381?
15:33 dj-death: bbrezillon: I think just a replace of MESA_VK_ATTACHMENT_UNUSED in src/intel/vulkan/ might fix it
15:34 dj-death: what's the difference between MESA_VK_ATTACHMENT_UNUSED & MESA_VK_ATTACHMENT_NO_INDEX ?
15:35 bbrezillon: NO_INDEX means the input attachment in the shader has no explicit index
15:35 bbrezillon: (depth/stencil attachments)
15:35 bbrezillon: UNUSED means the attachment is not used
15:36 bbrezillon: which is different
15:36 bbrezillon: so we can't really s/UNUSED/NO_INDEX/
15:36 dj-death: I'm not sure what "no explicit index" actually means
15:37 bbrezillon: layout (input_attachment_index = 1, binding = 1) uniform subpassInput inputDepth; // has an explicit index
15:38 bbrezillon: layout (binding = 1) uniform subpassInput inputDepth; // no explicit index
15:38 bbrezillon: (that's GLSL syntax BTW)
15:39 dj-death: hmmm
15:39 dj-death: I don't really get how this is related to renderpasses
15:41 dj-death: oh okay, looking at the introduction commit
15:41 bbrezillon: https://docs.vulkan.org/features/latest/features/proposals/VK_KHR_dynamic_rendering_local_read.html#_input_attachment_mapping
15:41 dj-death: then Anv should replace idx == MESA_VK_ATTACHMENT_UNUSED by (idx == MESA_VK_ATTACHMENT_UNUSED || idx == MESA_VK_ATTACHMENT_NO_INDEX)
15:42 bbrezillon: are you sure that's correct? NO_INDEX means the depth/stencil buffer might be read by the shader
15:42 bbrezillon: so you might have a feedback loop here
15:44 bbrezillon: the problem is, when no input attachment remapping is provided, the depth/stencil attachment is mapped to the NO_INDEX input attachment
15:44 dj-death: yeah, I don't know
15:44 bbrezillon: but it will only be read if the read reads an input attachment with NO_INDEX
15:44 dj-death: I'll try that commit to see
15:45 bbrezillon: I tried various things, and the only way I could get rid of this failure was to drop the test on the idx entirely, but I'm sure it's incorrect :-)
15:47 bbrezillon: I guess what we'd need is some sort of frag_shader_reads_depth_or_stencil test instead
16:06 dj-death: I guess something is missing the initialization of the dynamic state
16:06 dj-death: probably at BeginRendering
16:12 bbrezillon: what do you mean?
16:14 bbrezillon: the dynamic ial state will expose NO_INDEX for the depth/stencil buffer if no VkRenderingInputAttachmentIndexInfoKHR is provided (either dynamically or through vkCmdSetXxx)
16:16 bbrezillon: But this is just a remapping information. If the depth/stencil attachment is not read, and the remapping says NO_INDEX for DS, the attachment is still not read
16:25 dj-death: yeah we're probably leaning too much on the runtime data
16:25 dj-death: we should look at the pipeline too
16:41 dj-death: are the collobora intel runners offline?
17:15 daniels: dj-death: yes atm