This section is Informative. It is included to aid in implementors' understanding of sparse resources.
Device Virtual Address. The basic sparseBinding
feature allows the resource to reserve its own
device virtual address range at resource creation time rather than relying on a
bind operation to set this. Without any other creation flags, no other
constraints are relaxed compared to normal resources. All pages must be
bound to physical memory before the device accesses the resource.
The sparse residency features allow
sparse resources to be used even
when not all pages are bound to memory. Hardware that supports access to
unbound pages without causing a fault may support
residencyNonResidentStrict
.
Not faulting on access to unbound pages is not enough to support
sparseResidencyNonResidentStrict
. An implementation must also
guarantee that reads after writes to unbound regions of the resource always
return data for the read as if the memory contains zeros. Depending on the
cache implementation of the hardware this may not always be possible.
Hardware that does not fault, but does not guarantee correct read values
will not require dummy pages, but also must not support
sparseResidencyNonResidentStrict
.
Hardware that cannot access unbound pages without causing a fault will require the implementation to bind the entire device virtual address range to physical memory. Any pages that the application does not bind to memory may be bound to one (or more) “dummy” physical page(s) allocated by the implementation. Given the following properties:
It is sufficient for each host process to allocate these dummy pages and use them for all resources in that process. Implementations may allocate more often (per instance, per device, or per resource).
Binding Memory. The byte size reported in VkMemoryRequirements
::size
must be
greater than or equal to the amount of physical memory required to fully
populate the resource. Some hardware requires “holes” in the device
virtual address range that are never accessed. These holes may be included
in the size
reported for the resource.
Including or not including the device virtual address holes in the resource
size will alter how the implementation provides support for
VkSparseImageOpaqueMemoryBindInfo
. This operation must be supported
for all sparse images, even ones created with
VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT
.
![]() | editing-note |
---|---|
@ntrevett suggested expanding the NOTE tag below to encompass everything from “The cost is…” in the first bullet point through the current note. TBD. |
resourceOffset
is simply a device virtual
address offset and the implementation does not require any sophisticated
logic to determine what device virtual address to bind. The cost is that
the application can allocate more physical memory for the resource than
it needs.
resourceOffset
to the actual device virtual address intended to be
mapped.
![]() | Note |
---|---|
If the application always uses Since |
Binding Metadata Memory. All metadata for sparse images have their own sparse properties and are embedded in the mip tail region for said properties. See the Multiaspect section for details.
Given that metadata is in a mip tail region, and the mip tail region must
be reported as contiguous (either globally or per-array-layer), some
implementations will have to resort to complicated offset → device virtual
address mapping for handling VkSparseImageOpaqueMemoryBindInfo
.
To make this easier on the implementation, the
VK_SPARSE_MEMORY_BIND_METADATA_BIT
explicitly denotes when
metadata is bound with VkSparseImageOpaqueMemoryBindInfo
. When this
flag is not present, the resourceOffset
may be treated as a strict
device virtual address offset.
When VK_SPARSE_MEMORY_BIND_METADATA_BIT
is present, the
resourceOffset
must have been derived explicitly from the
imageMipTailOffset
in the sparse resource properties returned for the
metadata aspect. By manipulating the value returned for
imageMipTailOffset
, the resourceOffset
does not have to
correlate directly to a device virtual address offset, and may instead be
whatever values makes it easiest for the implementation to derive the
correct device virtual address.