00:20DavidHeidelberg: I'm I only one who is ignorant, or anyone used deqp-runner suite verbose in the CI to figure out which CI tests freeze machine?
00:20DavidHeidelberg: I love the output of "-vvv"
14:09warpme: guys: i'm updating in my distro (multimedia appliance) mesa to 24.1.0. After adding required libclc, cross-compilation fails like this: https://gist.github.com/warpme/4cf1b49d0448faf1183528b9d31407fb Pls look on L738. I compared what files my cross-compiled libclc installs with i.e. archlinux libclc ( https://archlinux.org/packages/extra/any/libclc/files/ ) and basically it looks the same. May somebody hint me where issue might be?
16:05karolherbst: warpme: looks like your cross compilation setup is broken
16:06karolherbst: "/home/piotro/minimyth2-x86_64-next/script/lib/SPIRV-LLVM-Translator/work/main.d/SPIRV-LLVM-Translator-ad99707fd80189dca0ca76ed89946ae383e9a030_build/SPIRV-Headers/include/spirv/unified1/spirv.hpp:644: note: name ‘BuiltInPosition’ differs from name ‘Position’ defined in another translation unit"
16:53warpme: karolherbst : many thx for looking on this. Looking on build artefacts I see i have multiple variants of spirv.hpp: from glslang; from SPIRV-Headers-vulkan-sdk-1.3.283.0 and within SPIRV-LLVM-Translator. As all this spirv is actively developed - i used most current sources for all 3: glslang; SPIRV-Headers; SPIRV-LLVM-Translator Is this not enough?
17:14karolherbst: warpme: I think you have to make sure that everything gets compiled with the same spirv-headers
17:15karolherbst: bit I know that things can go wrong if mesa and the spirv-llvm-translator uses different headers
17:19warpme: indeed: what will be your advisory: should i assume https://github.com/KhronosGroup/SPIRV-Headers is reference and ask SPIRV-LLVM-Translator to use these headers instead of build-in?
17:20karolherbst: yeah
17:23warpme: For spirv-llvm-translator i can go with -DLLVM_EXTERNAL_SPIRV_HEADERS_SOURCE_DIR=</path/to/headers_dir> Do i need also play with pointing mesa into right headers dir or only spirv-llvm-translator needs to be directd?
17:23karolherbst: I think it doesn't matter much for mesa...,
17:24warpme: qll. many thx!
18:50mephi: Fellas I appear to have a vulkan mesa issue and would like to know if anyone can help me debug. I have a dual gpu setup (nvidia-proprietary + Iris Xe Graphics [raptor lake]), I am running wayland kde, and if I try to explicitly render something in vulkan with the intel gpu, it doesn't work. Running `VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation MESA_VK_DEVICE_SELECT='8086:a7a0' vkgears` creates an empty black window with the following error being printed
18:50mephi: to console repeatedly:
18:50mephi: VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum: 1461184347 - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xfab64d0000000002, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR(): Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://www.
18:50mephi: khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
18:50mephi: Objects: 1
18:50mephi: [0] 0xfab64d0000000002, type: 5, name: NULL
18:51mephi: Would anyone know where to start? Or how to track down the issue? I am using the latest mesa compiled straight from the gitlab repo
19:02mephi: Steping through the vk gears code, the vulkan validation error is thrown in line 1536 `VkResult result = vkAcquireNextImageKHR(device, swap_chain, UINT64_MAX,back_buffer_semaphore, VK_NULL_HANDLE,&index);` result is VK_SUCCESS. I assume the semaphore the validation layer is reffering to is the back_buffer_semaphore.
19:05mephi: Stepping through the code without setting MESA_VK_DEVICE_SELECT (which defaults to nvidia proprietery) still causes the validation layer to throw the same error but this time an image is actually displayed so maybe this error is unrelated.
19:59CashDash123: Not X related,but does anyone have issues getting the R300 based M24 to boot in KMS
21:05illwieckz: CashDash123, AGP?
21:05CashDash123: PCI
21:05illwieckz: ah
21:05illwieckz: AMD CPU?
21:06CashDash123: Pentium M
21:06illwieckz: so I have no idea
21:07illwieckz: (I know there is an issue with PCI AMD GPU on AMD CPU, affecting AGP since the day AGP has been disabled by default to rely on underlying PCI instead)
21:07illwieckz: but that kind of issue doesn't affect systems with Intel CPUs as far as I know
21:07CashDash123: seeing if I somehow forgot to disable framebuffer support in kernel I remember reading it conflicts the kernel driver
21:23DavidHeidelberg: karolherbst: I would merge at least the commit with the new errors list for start and keep the MR open? https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/919
22:06karolherbst: DavidHeidelberg: maybe? It's probably fine either way, because the CL tests aren't really that reliable in the first place, but yeah...
22:07DavidHeidelberg: well, I don't want to reduce reliability, thou now it fails in CI and I don't know where
22:07DavidHeidelberg: so printing the code seems to be useful
22:08karolherbst: yeah..., though I think something else is up
22:09karolherbst: though dunno...
22:10karolherbst: DavidHeidelberg: anyway, adding the new errors is totally fine, I just don't know enough about those CL tests to really say if thread safety matters at all
22:55mephi: Hey yall, I made a patch for vkgears.c in mesa/demos but I don't know how to exactly use gitlab. I seem to be unable to make forks as it tells me "Limit reached You cannot create projects in your personal namespace. Contact your GitLab administrator." I also don't appear to have permissions to make merge requests. Could someone help me?
23:03Sachiel: mephi: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new?issuable_template=User%20verification
23:07mephi: Sachiel: Thanks!!