kc3-lang/angle

2020-05-04T00:44:16

Fix validation errors & re-enable VulkanExternalImageTest clear tests These tests previously encountered errors attempting to transfer images from VK_QUEUE_FAMILY_EXTERNAL back to itself (this is not valid because one of the queues families in a memory barrier must be the family of the queue that executes the barrier). These invalid transfers were made because our ownership tracking started all resources in the "externally owned" state, with the expectation that the first operation on the resource would be a call to glWaitSemaphoreEXT to acquire ownership. It is far from clear that a call to glWaitSemaphoreEXT is always required to gain ownership of a resource. The EXT_external_objects extension inherits Vulkan's semantics, and what the Vulkan spec says is that the first entity to access a resource implicitly assumes ownership (see 11.7.1 "External Resource Sharing"). Binding a resource to memory does not constitute an access to that resource, or affect its ownership. Allocations should not be accesses, either; they happen at a lower level and the entire discussion about determining initial ownership from first access would serve no purpose if the mere allocation of the underlying memory was sufficient to assume ownership. This patch therefore adjusts the initial queue family ownership of resources created in memory objects to be the ANGLE renderer's queue family, just like a locally allocated image would be. Since this ownership state may not be correct (an external API may have already accessed the image, and assumed ownership) we must relax our assertions to allow a call to glWaitSemaphoreEXT while in this state. For images, this is only permitted while the layout is undefined. An alternative would be to set the initial queue family to a sentinel value that indicates that we don't know, but that would require checking for this value before making any accesses, and only then asserting local ownership. There's no real upside to this; the net effect of the first access rule is that we must effectively assume ownership until proven otherwise. Besides appearing to be the spec's intent, this change simplifies some usage scenarios because a queue submission is not required in the source Vulkan instance in order to allocate resources that will be initially accessed from GL. This seems especially important since there's no mechanism to allocate an external memory object from inside GL. The only downside is that the initial ambiguity in ownership prevents us from diagnosing certain errors, but this limitation is temporary; ownership becomes clear as soon as there is at least one access or at least one synchronization operation affecting the resource. Bug: angleproject:4229 Change-Id: Ibca2bfe373810c55352b1d849d07733d5fcfe5f4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2178946 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>