Bug 108925

Summary: vkCmdCopyQueryPoolResults(VK_QUERY_RESULT_WAIT_BIT) for timestamps with large query count hangs
Product: Mesa Reporter: Alex Smith <asmith>
Component: Drivers/Vulkan/radeonAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: major    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: Test case
New test case

Description Alex Smith 2018-12-03 12:26:29 UTC
Created attachment 142700 [details]
Test case

According to the Vulkan spec we need VK_QUERY_RESULT_WAIT_BIT here to ensure that all previous query commands have written a result. Using that on RADV with a large query count causes a GPU hang.

Attached a test case which reproduces this. Hangs for me on a Vega 64, with latest git master and 18.3 branch. Doesn't hang if the query count is reduced (in my testing, 512 queries hangs but 256 doesn't), or if VK_QUERY_RESULT_WAIT_BIT is not used.
Comment 1 Alex Smith 2018-12-03 13:38:00 UTC
FWIW, doesn't occur on AMDVLK. As far as I can see, that is just using a barrier rather than waiting for each individual query value to be available.

Also, it looks like RADV is only waiting on the low 32 bits of the query value. Couldn't you get very unlucky and get a valid timestamp with the low 32 bits as 0xffffffff, which would hang?
Comment 2 Samuel Pitoiset 2018-12-04 13:39:12 UTC
I can confirm this, working on.
Comment 3 Samuel Pitoiset 2018-12-04 13:54:41 UTC
The problem has been introduced by:

commit 5d6a560a2986c9ab421b3c7904d29bb7bc35e36f
Author: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Date:   Tue Sep 25 20:26:58 2018 +0200

    radv: do not use the availability bit for timestamp queries
    It's unnecessary because we can just check if the timestamp
    is to different to the default value when a pool is created
    or resetted. Instead of waiting for the availability bit to
    be 1, we have to emit a not equal WAIT_REG_MEM for checking
    if the timestamp is ready.
    Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
Comment 4 Samuel Pitoiset 2018-12-04 15:53:02 UTC
Can you try this patch https://patchwork.freedesktop.org/series/53482/ ?
Comment 5 Alex Smith 2018-12-05 09:17:01 UTC
Created attachment 142732 [details]
New test case

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.