PRTs + input attachments: Verify FB attachments accessed by input attachments are fully backed by physical memory, as far as renderpass' render area is considered.

[karl-lunarg]

Issue by DominikWitczakAMD (MIGRATED)
Monday Sep 25, 2017 at 11:08 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2088

---

Let X be an image defined as a FB attachment. Let X also be a partially-resident image.

Now, consider a renderpass with two subpasses:

• Subpass 1) renders to a color attachment which uses an image view whose parent image is X.
• Subpass 2) uses an input attachment which reads data rasterized in subpass 1.

Finally, let the renderpass use a DONT_CARE store op.

This use case could potentially be handled be differently by tilers and immediate renderers; one can imagine that tilers would use on-chip memory to store the rasterized contents, while the latter would stash the rendered data to image memory.

The issue arises if the writes, potentially only exercised by immediate renderers, touch pages without an actual physical memory backing. In such cases, it would be useful to have a validation check that would verify that all PRT tiles encapsulating the render area are actually backed by physical memory. If that is not the case, this could potentially lead to different results on different architectures.

The validation check would only be functional for mips that are not a part of miptails (because tile granularity breaks, as soon as we enter these), but it's probably better to warn developers about entering the "undefined behavior" land, rather than not letting them know about anything at all.

[jzulauf-lunarg]

@DominikWitczakAMD

It's not clear to me that the implementation is allowed to vary it's behavior in this way without warning the application it's possible. Meaning that there doesn't seem to be a validation issue getting undefined results from usage patterns that are defined to be undefined. Perhaps this belongs in #24?

31.4.1. Accessing Unbound Regions

The following member of VkPhysicalDeviceSparseProperties affects how data in unbound regions of sparse resources are handled by the implementation:

residencyNonResidentStrict

If this property is not present, reads of unbound regions of the image will return undefined values. Both reads and writes are still considered safe and will not affect other resources or populated regions of the image.

If this property is present, all reads of unbound regions of the image will behave as if the region was bound to memory populated with all zeros; writes will be discarded.