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.