cancel
Showing results for 
Search instead for 
Did you mean: 

OpenGL & Vulkan

ashalah
Adept I

vkAcquireNextImageKHR with 0 timeout returns VK_TIMEOUT instead of VK_NOT_READY

Jump to solution

Background: I have a use case where I want to call vkAcquireNextImageKHR with a timeout of 0 (so it doesn't block), and if no image is available and the call would block, I call it again with a UINT64_MAX timeout, but this time from a different thread. I do this because the original code is running inside a job system that is not allowed to make any blocking calls, but we don't want to incur extra latency of waiting for another thread to call vkAcquireNextImageKHR for us if the call could succeed immediately.

Anyway, the spec says when timeout is 0, vkAcquireNextImageKHR should return either VK_SUCCESS or VK_NOT_READY (or an error code), not VK_TIMEOUT, but I'm getting VK_TIMEOUT on Windows 10 64bit, HD7770 with driver 16.12.2. I will try with driver 17.1.1 as well today. VK_TIMEOUT is for when timeout is greater than 0 and less than UINT64_MAX.

This isn't a big issue, the workaround in my code is to just check for both VK_NOT_READY and VK_TIMEOUT, but I thought I'd report it anyway.

Tags (1)
0 Kudos
Reply
1 Solution

Accepted Solutions
dwitczak
Staff
Staff

Re: vkAcquireNextImageKHR with 0 timeout returns VK_TIMEOUT instead of VK_NOT_READY

Jump to solution

I've addressed the bug internally. The fix should go out in one of the upcoming driver releases.

View solution in original post

3 Replies
ashalah
Adept I

Re: vkAcquireNextImageKHR with 0 timeout returns VK_TIMEOUT instead of VK_NOT_READY

Jump to solution

No change in driver 17.1.1

0 Kudos
Reply
dwitczak
Staff
Staff

Re: vkAcquireNextImageKHR with 0 timeout returns VK_TIMEOUT instead of VK_NOT_READY

Jump to solution

Apologies for the awful delay from my end. Many thanks for reporting this issue, I'll have it resolved shortly.

dwitczak
Staff
Staff

Re: vkAcquireNextImageKHR with 0 timeout returns VK_TIMEOUT instead of VK_NOT_READY

Jump to solution

I've addressed the bug internally. The fix should go out in one of the upcoming driver releases.

View solution in original post