coldfeet has quit [Remote host closed the connection]
kts has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
kts has joined #dri-devel
f_ has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<karolherbst>
warpme: looks like your cross compilation setup is broken
<karolherbst>
"/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"
coldfeet has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
ced117_ has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
ced117 has joined #dri-devel
ced117_ has quit [Ping timeout: 480 seconds]
<warpme>
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?
minecrell9 has quit []
minecrell has joined #dri-devel
<karolherbst>
warpme: I think you have to make sure that everything gets compiled with the same spirv-headers
<karolherbst>
bit I know that things can go wrong if mesa and the spirv-llvm-translator uses different headers
nerdopolis has quit [Ping timeout: 480 seconds]
<warpme>
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?
<karolherbst>
yeah
<warpme>
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?
<karolherbst>
I think it doesn't matter much for mesa...,
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Haaninjo has joined #dri-devel
f_ has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
YunseongKim has joined #dri-devel
<mephi>
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
<mephi>
to console repeatedly:
<mephi>
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.
<mephi>
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
<mephi>
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.
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<mephi>
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.
sukuna has joined #dri-devel
fab has joined #dri-devel
nerdopolis has joined #dri-devel
iive has joined #dri-devel
mephi_ has joined #dri-devel
mephi has quit [Ping timeout: 480 seconds]
mephi_ has quit []
mephi_ has joined #dri-devel
mephi_ has quit []
mephi has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
nerdopolis has quit [Ping timeout: 480 seconds]
<CashDash123>
Not X related,but does anyone have issues getting the R300 based M24 to boot in KMS
sukuna has quit [Remote host closed the connection]
sukuna has joined #dri-devel
bolson has joined #dri-devel
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
sukuna has quit [Remote host closed the connection]
<illwieckz>
CashDash123, AGP?
<CashDash123>
PCI
<illwieckz>
ah
<illwieckz>
AMD CPU?
<CashDash123>
Pentium M
<illwieckz>
so I have no idea
epoch101 has quit []
<illwieckz>
(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)
fab has quit [Quit: fab]
<illwieckz>
but that kind of issue doesn't affect systems with Intel CPUs as far as I know
<CashDash123>
seeing if I somehow forgot to disable framebuffer support in kernel I remember reading it conflicts the kernel driver
<karolherbst>
DavidHeidelberg: maybe? It's probably fine either way, because the CL tests aren't really that reliable in the first place, but yeah...
<DavidHeidelberg>
well, I don't want to reduce reliability, thou now it fails in CI and I don't know where
<DavidHeidelberg>
so printing the code seems to be useful
<karolherbst>
yeah..., though I think something else is up
<karolherbst>
though dunno...
nerdopolis has joined #dri-devel
<karolherbst>
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
<mephi>
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?