Vulkan-Docs/doc/specs/vulkan/appendices/VK_KHR_dedicated_allocation.txt
Jon Leech 0cc6bba634 Change log for September 15, 2017 Vulkan 1.0.61 spec update:
* Bump API patch number and header version number to 61 for this update.

Github Issues:

  * Provide alternate length attributes (altlen=) in the XML schema, for
    those using length attributes to generate code instead of documentation
    (public issue 555).
  * Fix erroneous references to `latex:` being used for asciidoc math
    markup, rather than `latexmath:` (public pull request 556).
  * Add author ID to XML for Kazan software renderer (public pull request
    557).

Internal Issues:

  * Add the <<fundamentals-abi,Application Binary Interface>> section
    describing platform ABI requirements and recommendations, add examples
    of function and function pointer declarations to the
    <<boilerplate-platform-specific-calling-conventions, Platform-Specific
    Calling Conventions>> section, and remove related language that existed
    elsewhere in the specification (internal issue 64).
  * Describe where to document valid usage interactions of chained
    structures in the style guide, and fix one case now appearing in
    slink:VkBufferCreateInfo instead of the child
    slink:VkDedicatedAllocationBufferCreateInfoNV structure (internal issue
    715).
  * Add example to the style guide of describing enumerated types which are
    empty when the spec is built without relevant extensions enabled, and
    apply it to existing examples for
    elink:VkDescriptorSetLayoutCreateFlagBits and
    elink:VkSubpassDescriptionFlagBits (internal issue 864).
  * Add a note to the <<fundamentals-validusage-enums, Valid Usage for
    Enumerated Types>> section that the special values suffixed with
    etext:_BEGIN_RANGE, etext:_END_RANGE, etext:_RANGE_SIZE and
    etext:_MAX_ENUM are not part of the API and should: not be used by
    applications (internal issue 872).
  * Added note to flink:vkCmdUpdateBuffers explaining the performance
    penalty for copies done in this way, and why the upper copy limit is
    what it is (internal issue 952).
  * Update `VK_KHX_device_group` to split some functionality into the new
    `VK_KHR_bind_memory2` extension, and rename that functionality (internal
    issue 969).
  * Remove *Status* fields from extension appendices, since they are by
    definition published and complete by the time they reach the public
    github repository (internal issue 973).

Other Issues:

  * Update Data Format specification dependency to version 1.2 and change
    references to DF sections accordingly.
  * Update XML to make the pname:pAllocator parameter of
    flink:vkRegisterDeviceEventEXT and flink:vkRegisterDisplayEventEXT in
    the `VK_EXT_display_control` extension as optional.

New Extensions:

  * `VK_KHR_bind_memory2`
  * `VK_KHR_image_format_list`
  * `VK_KHR_maintenance2`
  * `VK_KHR_sampler_ycbcr_conversion`
2017-09-14 22:41:33 -07:00

162 lines
5.0 KiB
Plaintext

// Copyright (c) 2016-2017 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-08-07
*IP Status*::
No known IP claims.
*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:VkMemoryRequirements2KHR structure passed as
the pname:pMemoryRequirements parameter to a call to
fname:vkGetBufferMemoryRequirements2KHR or
fname:vkGetImageMemoryRequirements2KHR.
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.
=== 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
};
VkMemoryRequirements2KHR memoryRequirements =
{
VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2_KHR,
&dedicatedRequirements, // pNext
};
const VkImageMemoryRequirementsInfo2KHR imageRequirementsInfo =
{
VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2_KHR,
NULL, // pNext
image
};
vkGetImageMemoryRequirements2KHR(
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.