Created attachment 137687 [details] [review] Modification to the 'occlusionquery' demo to reproduce the issue Under certain circumstances, vkGetQueryPoolResults will always return VK_NOT_READY for a query pool, even when all of the requested queries should be available. When using VK_QUERY_RESULT_WAIT_BIT, the function never returns. The attached patch is a modification to Sascha Willems' 'occlusionquery' demo which triggers the issue. Tested on an RX 480, mesa-git as of d448954228e69fd1b4000ea13e28c2ba2832db13, with validation layers enabled. The following conditions have to be met in order to trigger this issue: - The query pool has to be fairly large (>= 32 queries) - vkCmdBeginQuery has to be called shortly or immediately after vkCmdResetQueryPool, outside a render pass instance. This issue was introduced with the following commit: [a41e2e9cf5f865f21e32cac2ed2e25dd21a05119] radv: allow to use a compute shader for resetting the query pool
Yeah, I think it's because we don't emit the cache flushes after resetting the query pool with a compute shader.
Created attachment 137690 [details] [review] workaround This fixes the issue for me, but I will probably come with a better solution a bit later.
Here's the fix https://patchwork.freedesktop.org/patch/207416/
Fixed. https://cgit.freedesktop.org/mesa/mesa/commit/?id=c956d0f4069cf39d8d3c57ebed8d905575e9ea34
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.