From 70194c9f1ab56f1ebe8f69cc4631df6e960e62ae Mon Sep 17 00:00:00 2001 From: Iago Toral Quiroga Date: Wed, 22 Mar 2017 08:35:39 +0100 Subject: [PATCH] anv/device: return VK_ERROR_DEVICE_LOST for errors during queue submissions So that we don't have to do things like rolling back address relocations in case that we ran into OOM after computing them, etc Also, make sure that if the queue submission comes with a fence, we set it up correctly so it behaves according to the spec after returning VK_ERROR_DEVICE_LOST. Reviewed-by: Jason Ekstrand --- src/intel/vulkan/anv_device.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c index bbf7a38c743..2a2a470ec99 100644 --- a/src/intel/vulkan/anv_device.c +++ b/src/intel/vulkan/anv_device.c @@ -1325,6 +1325,31 @@ VkResult anv_QueueSubmit( } out: + if (result != VK_SUCCESS) { + /* In the case that something has gone wrong we may end up with an + * inconsistent state from which it may not be trivial to recover. + * For example, we might have computed address relocations and + * any future attempt to re-submit this job will need to know about + * this and avoid computing relocation addresses again. + * + * To avoid this sort of issues, we assume that if something was + * wrong during submission we must already be in a really bad situation + * anyway (such us being out of memory) and return + * VK_ERROR_DEVICE_LOST to ensure that clients do not attempt to + * submit the same job again to this device. + */ + result = VK_ERROR_DEVICE_LOST; + + /* If we return VK_ERROR_DEVICE LOST here, we need to ensure that + * vkWaitForFences() and vkGetFenceStatus() return a valid result + * (VK_SUCCESS or VK_ERROR_DEVICE_LOST) in a finite amount of time. + * Setting the fence status to SIGNALED ensures this will happen in + * any case. + */ + if (fence) + fence->state = ANV_FENCE_STATE_SIGNALED; + } + pthread_mutex_unlock(&device->mutex); return result; -- 2.30.2