On 12/5/18 7:24 PM, Juan A. Suarez Romero wrote:
On Wed, 2018-12-05 at 09:52 +, Alex Smith wrote:
As done for vkCmdBeginQuery() already. Prevents timestamps from being
overwritten by previous vkCmdResetQueryPool() calls if the shader path
was used to do the reset.
Bugzilla: https://bugs.f
On Wed, 2018-12-05 at 09:52 +, Alex Smith wrote:
> As done for vkCmdBeginQuery() already. Prevents timestamps from being
> overwritten by previous vkCmdResetQueryPool() calls if the shader path
> was used to do the reset.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108925
> Fixe
On 12/5/18 11:15 AM, Alex Smith wrote:
Thanks. Though this fixes the 100% repro hang, I think your first patch
is still needed as well to handle getting 0x in the low 32 bits.
Yeah, it's still needed. Though I think it should be enough to wait on
the high 32bits as suggested by Bas.
Thanks. Though this fixes the 100% repro hang, I think your first patch is
still needed as well to handle getting 0x in the low 32 bits.
On Wed, 5 Dec 2018 at 10:04, Samuel Pitoiset
wrote:
> Yes, this is correct, indeed.
>
> The issue wasn't present because we used EOP events before remo
Yes, this is correct, indeed.
The issue wasn't present because we used EOP events before removing the
availability bit.
Btw, just noticed that we should reset pending_reset_query directly in
si_emit_cache_flush() to reduce the number of stalls. I will send a patch.
Also note that fill CP DM
As done for vkCmdBeginQuery() already. Prevents timestamps from being
overwritten by previous vkCmdResetQueryPool() calls if the shader path
was used to do the reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108925
Fixes: a41e2e9cf5 ("radv: allow to use a compute shader for resetting
