vulkan info exits early if instance creation fails for one GPU of several #491
Assignees
Labels
Comments
Is the AMD switchable graphics layer present at all? Maybe thats what originally returning the error. Vulkaninfo generally throws its hands up in the air if any vulkan function fails, because if it did continue, it might hard crash later or report incorrect information. |
|
Sorry, I don't know what the "AMD switchable graphics layer" is. I'm using the latest vulkan loader and tools trees. The error message is an example. It's the same with the latest code. I understand vulkaninfo throwing up its hands if some things fail, but I've hacked the code so that the VK_ERROR_OUT_OF_MEMORY I described above is not special-cased by the loader and then it works as I'd expect. I guess should have probably filed this issue with the loader and not tools. |
|
Ah now that I see you were referring to loader code, rather than vulkaninfo code, the changes you made make sense. Looking at the loader logic there, I think the 'bail on OUT_OF_HOST_MEMORY ' (OOHM) is intended, as that error is used to signal that malloc has failed, and if the driver can't do what it needs to and returns OOHM, then neither the loader can. A driver returning INITIALIZATION_FAILED (INIT_FAILED) then being skipped over is consistent since it means that specific driver didn't succeed (and we should remove it from the list of enabled drivers) and then try to load the other drivers on the system. If AMDVLK is indeed returning OOHM when it should be returning INIT_FAILED, then vulkaninfo shouldn't be affected. Though, if AMDVLK returns INIT_FAILED but the intel drivers aren't reported, then something else is amiss. |
|
Yeah, I think the root bug may be in the AMDVLK driver and I've reported it to them. But I have a hunch they're going to say that it's a loader bug. IMHO, it's seems very unlikely that the driver would really run out of host memory during vkCreateInstance. "host memory" here means ordinary heap memory in the process, right? |
|
Yes, Host memory should refer to regular malloc'd memory. |
|
I have the similar issue, but with a different error. $ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json vulkaninfoArch Linux |
|
@H5117 Can you set the env-var |
|
@charles-lunarg Here is the output: vulkaninfo.txt. |
|
This looks more and more like an issue with the driver. The Nvidia driver should either: not be found because it doesn't support vulkan or not report support for any physical devices. However I cannot rule out the possibility that a loader bug is causing this issue. But generally speaking, only SDK versions of the loader & tooling is validated. Using individual header updates means you are liable to include bugs that were introduced but fixed during SDK. Can you update to 1.2.176 and rerun the code? |
|
The "NVIDIA Corporation GK208B [GeForce GT 730]" device should support Vulkan. I would be interested in seeing the callstack for the crash. |
|
The same behavior with vulkan-icd-loader 1.2.176-1 and vulkan-tools 1.2.176-1. Stack trace with -DCMAKE_BUILD_TYPE=ReleaseStack trace with -DCMAKE_BUILD_TYPE=Debug |
|
Maybe it is worth to note that I don't have a monitor attached to the Nvidia card, it is used as OpenCL device only. But IMHO |
|
In this case, vkcube is crashing because a call to Line 3685 in 6149e30 I do agree that the error reporting could be better, but I assert (heh) that vkcube did what it could to verify that the system can support surfaces (by verifying if VK_KHR_surface and the platform specific surface extension are present and enabled), and then attempted to query the surface info (formats, support, capabilities, etc) and thats when it failed. I am not the vkcube maintainer, so my experience with that codebase is limited, as such it is very feasible that vkcube could be doing more to ensure that it works. As for vulkaninfo, that definitely is an issue, vulkaninfo should be more resilient to faults. Though, if there is an issue where the vulkan-loader reports support for surface extensions but crashes in calls to them (ie what vkcube could be suffering from), then vulkaninfo has the same limitation of only being able to check for those extensions to determine support. |
|
The spec declares If we do attempt to call
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a multi-GPU setup (built-in Intel GPU, external GPU enclosure with AMD). If both the Intel and AMD GPUs are available (powered on, kernel modules loaded, etc), vulkaninfo works as expected, printing details of both GPUs.
However, if the external GPU is not available, vulkaninfo exits early with an error:
/build/vulkan-tools-1.1.130.0~rc1/vulkaninfo/vulkaninfo.h:368: failed with ERROR_OUT_OF_HOST_MEMORY
No info about the available Intel GPU is printed.
The problem is caused by two issues:
I looked at commit 7fc1edea087f77c165fdfad060bc07481526b39e but it's not clear to me why VK_ERROR_OUT_OF_MEMORY is handled specially. My issue is fixed if I simply don't check for VK_ERROR_OUT_OF_MEMORY.
The text was updated successfully, but these errors were encountered: