vkAcquireDrmDisplayEXT: Invalid physicalDevice #823
Comments
|
This is very likely due to the recent Handle Validation that went into the loader. The warning you are seeing is unrelated, so its safe to ignore. What the assert is saying is that the The layers on your system aren't ones I know to cause issues here, but it wouldn't be a bad idea to try disabling them one by one to see if they are the source of the problem. Run the app with VK_LOADER_DEBUG=layer to get the disable-environment variable for each layer. Also, it wouldn't be a bad thing to get a stacktrace if you can, would be good to know if its from the loader, the layer, or somewhere entirely else. |
|
Is this an issue from the driver? I'm on Mesa 21.3.5 and I think the Vulkan 1.3 is upstream but not released. Here's the log from Monado (the program im trying to run) wiith |
|
There doesn't appear to be any layers doing weird things, which is good. My hunch is that the application is calling |
|
Here's the trace with the mesa validation layers installed, asserts here Without the layers, it assers there I don't understand how the physical device can be invalid, I have only one GPU. Is it the creation that is at fault? |
|
Okay yeah this is really strange, and shouldn't be coming from your code. Or at least not directly. But without source code I can't fully rule it out. If you have source code that you can share, that would be stellar, otherwise I understand not everything can be shared. If you are calling other physical device functions before vkAcquireDrmDisplayEXT successfully, then that would indicate its unlikely to be in your code. But this is just a strange issue. Nothing seems to be clearly amiss. |
|
It is indeed very strange, I investigated it yesterday and found out that the result with and without the layers installed are different. The same kind of crash happens (corrupted physical device) at different places. I ran the program with valgrind all night and it produced a very weird stacktrace around where the code crash, I'll investigate it further monday. I put out some prints in the loader and the physical device is all good until it gets corrupted. The code I'm working on is all open source, it's Monado on Wayland with the Valve Index, and using onnxruntime for hand tracking. I am rerunning valgrind to get a log, I'll share it when it finishes. |
|
Hmm the source code for static inline VkPhysicalDevice loader_unwrap_physical_device(VkPhysicalDevice physicalDevice) {
struct loader_physical_device_tramp *phys_dev = (struct loader_physical_device_tramp *)physicalDevice;
if (PHYS_TRAMP_MAGIC_NUMBER != phys_dev->magic) { //possible crash here if phys_dev has been corrupted.
return VK_NULL_HANDLE;
}
return phys_dev->phys_dev;
}Definitely will take a valgrind log if you have one (or is that a valgrind output already that I'm seeing?). |
|
There you go valgrind.log What you were seeing is the last thing valgrind outputs before ending. |
|
I can try to poke around the code some more (already did some searching to no avail) but without any further evidence to the contrary this appears to be an application bug. Can you try using a more recent vulkan-loader? We recently included some big improvements to the handling of physical device enumeration and its possible that could be having an effect. |
|
I messed around with a few things and the problem seems to be gone on its own. I still can't explain why I got it in the first place but I have not experienced it again in the past week. I'll close the issue but I'll add more info in case the bug happens again or if I get why it happened in the first place. Thanks for your time. |
|
Tried again today with 4c90ec3 and the issue is gone. Edit: Same with v1.3.206 |
|
Strange. But thanks for checking in that the issue isn't present. |
|
@bl4ckb0ne Just a followup, it was likely caused by a bug on our end. |
|
Good to know there's finally an answer, this bug drove me mad for a week! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since the upgrade to 1.3.204, I've been unable to use the functions from VK_EXT_acquire_drm_display. There's an assert somewhere in the loader that is triggered, here's the crash log with
VK_LOADER_DEBUG=allI saw the
LDP_DRIVER_7warning message a lot in my logs, I don't know if it's related.Here's the output from
vulkaninfo: vulkaninfo.logThe instance version is
1.3.204but my physical device (AMD RADV POLARIS10) is1.2.195I've been able to run vkcube and vkcubepp without issue.
The text was updated successfully, but these errors were encountered: