You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 19, 2018. It is now read-only.
PRTs + input attachments: Verify FB attachments accessed by input attachments are fully backed by physical memory, as far as renderpass' render area is considered.
#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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: