Description
Metal heaps do now allow us to specify offsets when performing allocations. This presents a few (related) problems:
- Aliasing is allowed on heaps, but only by specifying that an existing resource may now be freely aliased by future allocations. This limits our ability to translate aliasing in the user's (emulated) view of the memory space to aliasing on the device.
- Heaps require the user to query how much memory is available at a particular alignment, which may vary depending on how the driver decided to place the existing resources. There is no reason that this would match up with how the user has laid out memory from their perspective, and could result in an allocation failing exogenously.
- The complex aliasing interactions allowed in Vulkan (e.g. when writing to one host-accessible alias and reading the same data from another) have no native equivalent. Modifying a resource that is aliased with another leads to the second's content becoming undefined.
A possibility for dealing with (1) and (2) would be to simply fall back on allocation of resources off of the heap when the user's allocation pattern cannot be mapped properly; the user would simply be given a pass if they would have technically invoked undefined behavior by incompatible access of aliased resources.
I don't think there is any way to work around (3). In theory we could simulate such aliasing by allocating a buffer and making texture views of range within it, but such views have lots of restrictions in the API (2D textures only, alignment, etc.) and it would be difficult to detect when we needed to do that without inducing a lot of overhead.
For the purposes of #1226, IIRC Vulkan implementations are allowed to advertise that they do not support linear tiling for any formats, which would prevent a user from attempting to invoke (3) without violating the API.