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

[Dave Airlie]

On 27 July 2017 at 00:06, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> 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?

It can, but I run it inside piglit. But even just running one test
twice in a row causes the
problem.

>
> 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?

Writes to an address that is no longer valid, the address was valid in
the last compute
shader execution in the previous process.

Yes just get an SI, build radv, run
./deqp-vk --deqp-case=dEQP-VK.memory.pipeline_barrier.host_write_uniform_texel_buffer.1024
run it again, viola faults.

Dave.