Vulkan-Docs/appendices/VK_KHR_dedicated_allocation.txt
Jon Leech 56e0289318 Change log for January 05, 2019 Vulkan 1.1.97 spec update:
* Update release number to 97.

Public Issues:

  * Add a special case to the <<renderpass-compatibility, Render Pass
    Compatibility>> rules allowing single-subpass renderpasses to be
    compatible even if they have different resolve attachment references
    (public issue 835).
  * Fix the miss shader binding table record address rule in the
    <<shader-binding-table-indexing-rules, Miss Shaders>> section to index
    by code:missIndex, not code:sbtOffset (public issue 875).

Internal Issues:

  * Add a missing anchor to the elink:VkSamplerCreateFlagBits language
    (internal issue 1483).
  * Add missing implicit valid usage include for slink:VkHdrMetadataEXT and
    corresponding `noautovalidity` attributes in `vk.xml` for the
    externally-defined metadata properties (internal issue 1514).
  * Remove restrictions on the `mask` parameter of SPIR-V's
    code:OpGroupNonUniformXor in the <<spirvenv-module-validation,
    Validation Rules within a Module>> appendix (internal merge request
    2971).
  * Restore `noautovalidity` attribute for
    slink:VkPipelineViewportWScalingStateCreateInfoNV::pname:pViewportWScalings
    in `vk.xml` (internal merge request 2975).
  * Update copyright dates on Khronos-copyrighted files to 2019 (internal
    merge request 2980).

New Extensions:

  * `VK_KHR_depth_stencil_resolve`
  * `VK_EXT_buffer_device_address`
  * `VK_EXT_memory_budget`
  * `VK_EXT_memory_priority`
  * `VK_EXT_validation_features`
2019-01-05 19:40:12 -08:00

170 lines
5.2 KiB
Plaintext

// Copyright (c) 2016-2019 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_KHR_dedicated_allocation.txt[]
*Last Modified Date*::
2017-09-05
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- Promoted to Vulkan 1.1 Core
*Contributors*::
- Jeff Bolz, NVIDIA
- Jason Ekstrand, Intel
This extension enables resources to be bound to a dedicated allocation,
rather than suballocated.
For any particular resource, applications can: query whether a dedicated
allocation is recommended, in which case using a dedicated allocation may:
improve the performance of access to that resource.
Normal device memory allocations must support multiple resources per
allocation, memory aliasing and sparse binding, which could interfere with
some optimizations.
Applications should query the implementation for when a dedicated allocation
may: be beneficial by adding sname:VkMemoryDedicatedRequirementsKHR to the
pname:pNext chain of the sname:VkMemoryRequirements2 structure passed as the
pname:pMemoryRequirements parameter to a call to
fname:vkGetBufferMemoryRequirements2 or fname:vkGetImageMemoryRequirements2.
Certain external handle types and external images or buffers may: also
depend on dedicated allocations on implementations that associate image or
buffer metadata with OS-level memory objects.
This extension adds a two small structures to memory requirements querying
and memory allocation: a new structure that flags whether an image/buffer
should have a dedicated allocation, and a structure indicating the image or
buffer that an allocation will be bound to.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR
** ename:VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR
=== New Enums
None.
=== New Structures
* slink:VkMemoryDedicatedRequirementsKHR
* slink:VkMemoryDedicatedAllocateInfoKHR
=== New Functions
None.
=== Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the
KHR suffix omitted.
The original type, enum and command names are still available as aliases of
the core functionality.
=== Issues
None.
=== Examples
[source,c++]
--------------------------------------
// Create an image with a dedicated allocation based on the
// implementation's preference
VkImageCreateInfo imageCreateInfo =
{
// Image creation parameters
};
VkImage image;
VkResult result = vkCreateImage(
device,
&imageCreateInfo,
NULL, // pAllocator
&image);
VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
{
VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
NULL, // pNext
};
VkMemoryRequirements2 memoryRequirements =
{
VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
&dedicatedRequirements, // pNext
};
const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
{
VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
NULL, // pNext
image
};
vkGetImageMemoryRequirements2(
device,
&imageRequirementsInfo,
&memoryRequirements);
if (dedicatedRequirements.prefersDedicatedAllocation) {
// Allocate memory with VkMemoryDedicatedAllocateInfoKHR::image
// pointing to the image we are allocating the memory for
VkMemoryDedicatedAllocateInfoKHR dedicatedInfo =
{
VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR, // sType
NULL, // pNext
image, // image
VK_NULL_HANDLE, // buffer
};
VkMemoryAllocateInfo memoryAllocateInfo =
{
VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO, // sType
&dedicatedInfo, // pNext
memoryRequirements.size, // allocationSize
FindMemoryTypeIndex(memoryRequirements.memoryTypeBits), // memoryTypeIndex
};
VkDeviceMemory memory;
vkAllocateMemory(
device,
&memoryAllocateInfo,
NULL, // pAllocator
&memory);
// Bind the image to the memory
vkBindImageMemory(
device,
image,
memory,
0);
} else {
// Take the normal memory sub-allocation path
}
--------------------------------------
=== Version History
* Revision 1, 2017-02-27 (James Jones)
- Copy content from VK_NV_dedicated_allocation
- Add some references to external object interactions to the overview.
* Revision 2, 2017-03-27 (Jason Ekstrand)
- Rework the extension to be query-based
* Revision 3, 2017-07-31 (Jason Ekstrand)
- Clarify that memory objects created with
VkMemoryDedicatedAllocateInfoKHR can only have the specified resource
bound and no others.