mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-12 23:14:20 +00:00
0cc6bba634
* 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`
162 lines
5.0 KiB
Plaintext
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.
|