Vulkan-Docs/doc/specs/vulkan/appendices/VK_NV_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

130 lines
3.8 KiB
Plaintext

include::meta/VK_NV_dedicated_allocation.txt[]
*Last Modified Date*::
2016-05-31
*IP Status*::
No known IP claims.
*Contributors*::
- Jeff Bolz, NVIDIA
This extension allows device memory to be allocated for a particular buffer
or image resource, which on some devices can significantly improve the
performance of that resource.
Normal device memory allocations must support memory aliasing and sparse
binding, which could interfere with optimizations like framebuffer
compression or efficient page table usage.
This is important for render targets and very large resources, but need not
(and probably should not) be used for smaller resources that can benefit
from suballocation.
This extension adds a few small structures to resource creation and memory
allocation: a new structure that flags whether am image/buffer will 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_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV
** ename:VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_BUFFER_CREATE_INFO_NV
** ename:VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV
=== New Enums
None.
=== New Structures
* slink:VkDedicatedAllocationImageCreateInfoNV
* slink:VkDedicatedAllocationBufferCreateInfoNV
* slink:VkDedicatedAllocationMemoryAllocateInfoNV
=== New Functions
None.
=== Issues
None.
=== Examples
[source,c++]
--------------------------------------
// Create an image with
// VkDedicatedAllocationImageCreateInfoNV::dedicatedAllocation
// set to VK_TRUE
VkDedicatedAllocationImageCreateInfoNV dedicatedImageInfo =
{
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV, // sType
NULL, // pNext
VK_TRUE, // dedicatedAllocation
};
VkImageCreateInfo imageCreateInfo =
{
VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO, // sType
&dedicatedImageInfo // pNext
// Other members set as usual
};
VkImage image;
VkResult result = vkCreateImage(
device,
&imageCreateInfo,
NULL, // pAllocator
&image);
VkMemoryRequirements memoryRequirements;
vkGetImageMemoryRequirements(
device,
image,
&memoryRequirements);
// Allocate memory with VkDedicatedAllocationMemoryAllocateInfoNV::image
// pointing to the image we are allocating the memory for
VkDedicatedAllocationMemoryAllocateInfoNV dedicatedInfo =
{
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV, // 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);
--------------------------------------
=== Version History
* Revision 1, 2016-05-31 (Jeff Bolz)
- Internal revisions