On 27 July 2017 at 07:37, Dave Airlie wrote:
> On 27 July 2017 at 00:06, Nicolai Hähnle wrote:
>> On 26.07.2017 05:42, Dave Airlie wrote:
>>>
>>> From: Dave Airlie
>>>
>>> This seems like a workaround, but we don't see the bug on CIK/VI.
>>>
>>> On SI with the dEQP-VK.memory.pipeline_barrier.hos
On 27 July 2017 at 00:06, Nicolai Hähnle wrote:
> On 26.07.2017 05:42, Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> 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
On 26.07.2017 05:42, Dave Airlie wrote:
From: Dave Airlie
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
From: Dave Airlie
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 flu