[Mesa-dev] [Bug 105292] vkGetQueryPoolResults returns incorrect query status for large query buffers (bisected)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105292

            Bug ID: 105292
           Summary: vkGetQueryPoolResults returns incorrect query status
                    for large query buffers (bisected)
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Vulkan/radeon
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: philip.rebohle at tu-dortmund.de
        QA Contact: mesa-dev at lists.freedesktop.org

Created attachment 137687
  --> https://bugs.freedesktop.org/attachment.cgi?id=137687&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180228/cb3280ee/attachment.html>