Vulkan-Docs/doc/specs/vulkan/appendices/VK_NV_dedicated_allocation.txt
Jon Leech 82e0f83d43 Change log for February 10, 2017 Vulkan 1.0.40 spec update:
* Bump API patch number and header version number to 40 for this update.
  * There is a major build change in this release. We are now using the
    Ruby-based ``asciidoctor'' implementation, rather than the Python-based
    ``asciidoc'' implementation, to process the specification. While the
    actual specification markup changes were minimal, this requires a new
    set of build tools and a very different installation process, especially
    because we now use an experimental direct-to-PDF backend for Asciidoctor
    instead of Docbook->dblatex->PDF. It is no longer possible to build the
    Specification using asciidoc. See doc/specs/vulkan/README.adoc
    for some guidance on installing the new toolchain components.
  * There are some minor rendering issues in the PDF output due to teething
    problems with the asciidoctor toolchain, especially with mathematical
    equations. We are aware of these and working on them.

Github Issues:

  * Updated sample code for the <<sparsememory-examples-basic,sparse
    resource binding example>> (public issue 97).
  * Modify line and point clipping behavior in the
    <<vertexpostproc-clipping, Primitive Clipping>> section to allow for
    pop-free behavior. The ability to check for which behavior is
    implemented may be added a future feature or extension (public issue
    113).
  * Unify the discussions of implicit ordering throughout the spec, in
    particular in the new sections <<drawing-primitive-order, Primitive
    Order>>, <<primrast-order, Rasterization Order>>, and
    <<synchronization-implicit, Implicit Synchronization Guarantees>>; the
    discussion of <<synchronization-submission-order, submission order>>;
    and references elsewhere to these sections (public issue 133).
  * Clarify \<\<descriptorsets-compatibility,Pipeline Layout Compatibility>>
    language and introduce the term ``identically defined'' (public issue
    164).
  * Add a dependency to the +VK_EXT_debug_marker+ extension that's needed to
    reuse the object type enum from +VK_EXT_debug_report+, and moves the
    definition of that enum into +VK_EXT_debug_report+ where it should be
    (public issue 409).
  * Remove redundant valid usage statement from slink:VkImageBlit (public
    issue 421).
  * Update GL_KHR_vulkan_glsl to allow the ternary operator to result in a
    specialization constant (public issue 424).
  * Fix valid usage for flink:VkPipelineShaderStageCreateInfo (public issue
    426).
  * Correct typo in New Objects list for <<VK_EXT_debug_report>> (public
    issue 447).

Internal Issues:

  * Moved to asciidoctor for spec builds (internal issue 121).
  * Update style guide to describe where to put new extensions-specific
    asciidoc files, and what to name them (internal issue 626).
  * Add src/spec/indexExt.py to autogenerate registry index entries linking
    into the 1.0-extensions specification, instead of maintaining the index
    manually. (internal issue 642).
  * Autogenerate extension dependencies and lists of all extensions and all
    KHR extensions from the "supported" attributes in +vk.xml+. Execute
    +make config/extDependency.sh+ from +doc/specs/vulkan+ when a supported
    extension is added to vk.xml, to regenerate the dependency script. The
    consequence is that specifying a single extension to the +makeExt+
    script will automatically enable all extensions it depends on as well,
    and that the +makeAllExts+ and +makeKHR+ scripts do not need to be
    updated when a new extension is supported (internal issue 648).
  * Put extension appendices all at the same asciidoc section level, so KHR
    WSI extensions show up in the HTML index (internal issue 648).

Other Issues:

  * Imbed images in the generated HTML specs instead of loading them from
    the images/ directory.
  * Fix missing EXT in extension name
    (ename:VK_EXT_SWAPCHAIN_COLOR_SPACE_EXTENSION_NAME).
  * Add new +VK_EXT_SMPTE_2086_metadata+ extension.
  * In the <<platformCreateSurface_xlib,Xlib Surface>> section of the
    +VK_KHR_xlib_surface+ specification, add language warning users that
    they always need to call code:XinitThreads.
  * Use the term "presentable image" (rather than "swapchain image")
    consistently in +VK_KHR_swapchain+ and related extensions, and add a
    glossary term defining it.
  * Relocate the valid usage for samples of
    flink:vkGetPhysicalDeviceSparseImageFormatProperties2KHR::pname:pFormatInfo
    to be below the flink:VkPhysicalDeviceSparseImageFormatInfo2KHR
    structure.
2017-02-10 20:37:39 -08:00

145 lines
4.1 KiB
Plaintext

[[VK_NV_dedicated_allocation]]
== VK_NV_dedicated_allocation
*Name String*::
+VK_NV_dedicated_allocation+
*Extension Type*::
Device extension
*Registered Extension Number*::
27
*Status*::
Draft.
*Last Modified Date*::
2016-05-31
*Revision*::
1
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
*Contributors*::
- Jeff Bolz, NVIDIA
*Contacts*::
- Jeff Bolz (jbolz 'at' nvidia.com)
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