Fix errors in test_vulkan
#2183
Conversation
| externalMemoryHandleTypeList.push_back( | ||
| VULKAN_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD); | ||
| if (physical_device.hasExtension( | ||
| VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME)) |
There was a problem hiding this comment.
From Ben: Is this the right extension name to check for?
There was a problem hiding this comment.
There was a problem hiding this comment.
I would prefer we wait on merging this, it introduces a segfault for us. We would like to debug
There was a problem hiding this comment.
This is not the correct place to check for this extension. We already request it in vulkan_wrapper.cpp: line 146. This leads to a crash for us because VK_KHR_EXTERNAL_MEMORY_CAPABILITES_EXTENISION_NAME is not detected, and getSupportedVulkanExternalMemoryHandleTypeList() returns a 0 length list. When getSupportedVulkanExternalMemoryHandleTypeList()[0] is called, a crash is the result.
There was a problem hiding this comment.
@joshqti You're right. Additionally, from the VK_KHR_external_memory_capabilities section in the Vulkan specification:
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The
original type, enum, and command names are still available as aliases of the core functionality.
We use Vulkan 1.1, so we should not need to check this extension anyway.
That being said, we should have checks for the usage pattern that we intend with this type of memory, in our case it is export (from Vulkan), i.e. check that VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT is set for external memory that has the handle type: VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR.
I have updated the pull request to reflect this. Please let me know if you disagree and if you are continuing to see segmentation faults with this patch applied.
Add `CL_INVALID_SEMAPHORE_KHR` to the error string helper function. Signed-off-by: Ahmed Hesham <[email protected]>
Calling `clEnqueue{Wait,Signal}SemaphoresKHR` with an invalid
semaphore should return `CL_INVALID_SEMAPHORE_KHR` and not
`CL_INVALID_VALUE`.
Signed-off-by: Ahmed Hesham <[email protected]>
|
I believe test_consistency_external_image needs the similar change to skip the test if extension not supported. |
Updated both |
Check that the device supports exporting memory with a handle type `VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR` before adding an entry to the list of supported Vulkan external memory handle types. Signed-off-by: Ahmed Hesham <[email protected]>
If the device does not support the required extension, skip the test, instead of throwing an exception and failing. Signed-off-by: Ahmed Hesham <[email protected]>
This fixes three problems in
test_vulkan:clEnqueue{Wait,Signal}SemaphoresKHRwith an invalid semaphore should returnCL_INVALID_SEMAPHORE_KHRand notCL_INVALID_VALUE.When populating the list of supported external memory handle types for Vulkan, the types are unconditionally added to the list, without checking if the device supports it or not, this fix is namely for
VULKAN_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD.If a device does not support an optional extension (that is required for a test), the test should skip, not throw an exception and fail. A test failure should be reserved for the cases where a device claims support for an extension but then fails to execute the test correctly.