[Mesa-dev] [PATCH] radv: force compute flush at end of command stream.

[Nicolai Hähnle]

On 26.07.2017 05:42, Dave Airlie wrote:
> From: Dave Airlie <airlied at redhat.com>
> 
> This seems like a workaround, but we don't see the bug on CIK/VI.
> 
> On SI with the dEQP-VK.memory.pipeline_barrier.host_read_transfer_dst.*
> tests, when one tests complete, the first flush at the start of the next
> test causes a VM fault as we've destroyed the VM, but we end up flushing
> the compute shader then, and it must still be in the process of doing
> something.
> 
> Could also be a kernel difference between SI and CIK.

What do you mean by "destroyed the VM"? I thought the Vulkan CTS runs in 
a single process?

I guess it's fine as a temporary workaround, but I highly suspect we 
have some SI-specific bug related to these flushes; I've seen issues 
with radeonsi on amdgpu as well. It would be great to understand them 
properly.

What do the VM faults look like? How reproducible is this?

Cheers,
Nicolai


> 
> Signed-off-by: Dave Airlie <airlied at redhat.com>
> ---
>   src/amd/vulkan/radv_cmd_buffer.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
> index 4415e36..d185c00 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2233,8 +2233,10 @@ VkResult radv_EndCommandBuffer(
>   {
>   	RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
>   
> -	if (cmd_buffer->queue_family_index != RADV_QUEUE_TRANSFER)
> +	if (cmd_buffer->queue_family_index != RADV_QUEUE_TRANSFER) {
> +		cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_CS_PARTIAL_FLUSH;
>   		si_emit_cache_flush(cmd_buffer);
> +	}
>   
>   	if (!cmd_buffer->device->ws->cs_finalize(cmd_buffer->cs) ||
>   	    cmd_buffer->record_fail)
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.