You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If handleType is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT, the special value -1 for fd is treated like a valid sync file descriptor referring to an object that has already signaled
It is consistent with the option for implementations to return a -1 file descriptor when exporting a VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT from a VkSemaphore which is signaled
But vkGetSemaphoreFdKHR does not contain information about pFd's value -1 being valid option. Or really any other information about valid values beside being integer.
This has led to a bug in Chromium expecting pFd value to be always >= 0 when the result is VK_SUCCESS which has caused issues on Huawei devices whose driver returns -1 for already signaled semaphore.
The text was updated successfully, but these errors were encountered:
In the spec of VkImportSemaphoreFdInfoKHR it is stated:
But vkGetSemaphoreFdKHR does not contain information about pFd's value -1 being valid option. Or really any other information about valid values beside being integer.
This has led to a bug in Chromium expecting pFd value to be always >= 0 when the result is VK_SUCCESS which has caused issues on Huawei devices whose driver returns -1 for already signaled semaphore.
The text was updated successfully, but these errors were encountered: