SIGN IN SIGN UP

Fix tensor views with tensors that use deferred memory allocation (#5831)

Summary:
Pull Request resolved: https://github.com/pytorch/executorch/pull/5831

## Context

Fix one (hopefully) final kink with tensor views.

### The issue

When creating a tensor view of a tensor that uses deferred memory allocation, at the time the view is created, it will copy the handle of the original tensor's `VkImage`. However, since the `VkImage` is not yet bounded to memory, it will have have a `VkImageView` associated with it, and the tensor view will copy the `VkImageView` handle and `VK_NULL_HANDLE`.

Later, the original tensor is expected to be bound to an allocation, at which point it will create an image view and bind the `VkImage` to memory. However, this does not update its views, which will still have a null `VkImageView`.

If the tensor view is also bound to the allocation, then the same `VkImage` will be bound to the same memory multiple times which is against the Vulkan spec.

### The fix

Allow binding of `VulkanImage` and `VulkanBuffer` copies to only call the binding function if it is not  a copy; assume that the original tensor is responsible for binding to memory.

In `ComputeGraph`, when adding a tensor view, add the created `Value` as a user of any `SharedObject` of which the original tensor is also a user.
ghstack-source-id: 246029590
exported-using-ghexport

Reviewed By: jorgep31415

Differential Revision: D63790718

fbshipit-source-id: 1a93851ce77c3c685986dbc8a6300d9905ff60d2
S
Stephen Jia committed
7559ddd86474a4bfc01013f64df6619644e2ff63
Parent: e2e2129
Committed by Facebook GitHub Bot <facebook-github-bot@users.noreply.github.com> on 10/3/2024, 1:22:45 AM