dEQP already provides mechanisms for timeouts - we don't need to rely
on additional timeouts inside amber.
Worse still, if the timeout in amber is actually hit, Vulkan objects
are destructed while the commands are still queued, which can
cause crashes instead of a clean test failure.
Components: Vulkan
VK-GL-CTS Issue: 1971
Affects:
dEQP-VK.rasterization.provoking_vertex.*
dEQP-VK.graphicsfuzz.*
dEQP-VK.pipeline.vertex_only.*
dEQP-VK.spirv_assembly.instruction.compute.ptr_access_chain.*
dEQP-VK.spirv_assembly.instruction.compute.signed_int_compare.*
Change-Id: I3a2e1b1f2796af8eea7e26a8de27e8fc362b9653
return false;
m_recipe = new amber::Recipe();
+ m_recipe->SetFenceTimeout(1000 * 60 * 10); // 10 minutes
amber::Amber am;
amber::Result r = am.Parse(script, m_recipe);