Vulkan-Docs/doc/specs/vulkan/man/VkDescriptorPoolCreateInfo.txt
Jon Leech 1ca0ea1ef0 Change log for July 22, 2016 Vulkan 1.0.22 spec update:
* Bump API patch number and header version number to 22 for this update.

Github Issues:

  * Translate the subpass self-dependency language into concrete
    validity statements, and added a validity statement about the
    restrictions on layout parameters (public issue 267).
  * Add validity requirement that
    slink:VkAttachmentDescription::pname:finalLayout and
    slink:VkAttachmentReference::pname:layout must not be
    ename:VK_IMAGE_LAYOUT_UNDEFINED or
    ename:VK_IMAGE_LAYOUT_PREINITIALIZED (public issue 268).
  * Clarify that slink:VkSubpassDescription::pname:pResolveAttachments
    layouts are used. Make language consistent with other attachment
    arrays (public issue 270).
  * Changed 64-bit definition for
    dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE to work for x32 platform in
    +vk.xml+ and the resulting +vulkan.h+ (public issue 282).
  * Add missing error return code for
    flink:vkEnumerateInstanceExtensionProperties and
    flink:vkEnumerateDeviceExtensionProperties (public issue 285)
  * Fix several cases of stext::VkStructName.memberName markup to
    stext::VkStructName::pname:memberName, to match other usage in the
    spec, and describe this markup in the style guide (public issue
    286).
  * Modified validity language generation script to avoid redundant
    common ancestor language if covered by generic parent language, and
    used `Both' instead of `Each' when appropriate (public issue 288).

Internal Issues:

  * Add language about behavior of flink:vkAllocateDescriptorSets when
    allocation fails due to fragmentation, a new error
    ename:VK_ERROR_FRAGMENTED_POOL, and a Note explaining the situation
    (internal issue 309).
  * For the features of code:PointSize, code:ClipDistance, and
    code:CullDistance, the SPIR-V capability is required to be declared
    on use (read or write) rather than on decoration (internal issue
    359).
  * Have desktop versions of GLSL respect precision qualification
    (code:mediump and code:lowp) when compiling for Vulkan. These will
    get translated to SPIR-V's code:RelaxedPrecision decoration as they
    do with OpenGL ES versions of GLSL (ESSL). The default precision of
    all types is code:highp when using a desktop version (internal issue
    360).
  * Add validity statement for slink:VkImageCreateInfo specifying that
    multisampled images must be two-dimensional, optimally tiled, and
    with a single mipmap level (internal issue 369).
  * Add validity statements to slink:VkImageViewCreateInfo disallowing
    creation of images or image views with no supported features. Made
    some slink:VkImageViewCreateInfo validity statements more precise
    and consistent. Added a Note to the <<features,features>> chapter
    about formats with no features (internal issue 371).
  * Remove +manpages+ from default build targets. Nroff outputs
    containing imbedded latexmath will not render properly. Fixing this
    is a lot of work for limited use cases (internal issue 401).

Other Commits:

  * Fix flink:vkRenderPassBeginInfo::pname:clearValueCount validity
    statement to be based on attachment indices rather than the number
    of cleared attachments
    (Vulkan-LoaderAndValidationLayers/issues/601).
  * Convert registry documentation from LaTeX to asciidoc source and
    rename from +src/spec/readme.tex+ to +src/spec/registry.txt+.
  * Fix lack of Oxford commas in validity language.
  * Lots of cleanup of generator scripts and Makefiles to move extension
    list for generator into the script arguments instead of the body of
    genvk.py, and express better dependencies between XML, scripts, and
    generated files.
2016-07-23 03:15:48 -07:00

102 lines
3.8 KiB
Plaintext

// Copyright (c) 2014-2016 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
VkDescriptorPoolCreateInfo(3)
=============================
Name
----
VkDescriptorPoolCreateInfo - Structure specifying parameters of a newly created descriptor pool
C Specification
---------------
// refBegin VkDescriptorPoolCreateInfo - Structure specifying parameters of a newly created descriptor pool
Additional information about the pool is passed in an instance of the
sname:VkDescriptorPoolCreateInfo structure:
include::../api/structs/VkDescriptorPoolCreateInfo.txt[]
Members
-------
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags specifies certain supported operations on the pool.
Bits which can: be set include:
+
--
// refBegin VkDescriptorPoolCreateFlagBits - Bitmask specifying certain supported operations on a descriptor pool
include::../api/enums/VkDescriptorPoolCreateFlagBits.txt[]
--
+
If pname:flags includes
ename:VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT, then descriptor
sets can: return their individual allocations to the pool, i.e. all of
fname:vkAllocateDescriptorSets, fname:vkFreeDescriptorSets, and
fname:vkResetDescriptorPool are allowed. Otherwise, descriptor sets
allocated from the pool mustnot: be individually freed back to the pool,
i.e. only fname:vkAllocateDescriptorSets and fname:vkResetDescriptorPool are
allowed.
+
* pname:maxSets is the maximum number of descriptor sets that can:
be allocated from the pool.
* pname:poolSizeCount is the number of elements in pname:pPoolSizes.
* pname:pPoolSizes is a pointer to an array of sname:VkDescriptorPoolSize
structures, each containing a descriptor type and number of descriptors
of that type to be allocated in the pool.
Description
-----------
If multiple sname:VkDescriptorPoolSize structures appear in the
pname:pPoolSizes array then the pool will be created with enough storage
for the total number of descriptors of each type.
Fragmentation of a descriptor pool is possible and may: lead to descriptor
set allocation failures. A failure due to fragmentation is defined as
failing a descriptor set allocation despite the sum of all outstanding
descriptor set allocations from the pool plus the requested allocation
requiring no more than the total number of descriptors requested at pool
creation. Implementations provide certain guarantees of when fragmentation
mustnot: cause allocation failure, as described below.
If a descriptor pool has not had any descriptor sets freed since it was
created or most recently reset then fragmentation mustnot: cause an
allocation failure (note that this is always the case for a pool created
without the ename:VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT bit
set). Additionally, if all sets allocated from the pool since it was created
or most recently reset use the same number of descriptors (of each type) and
the requested allocation also uses that same number of descriptors (of each
type), then fragmentation mustnot: cause an allocation failure.
If an allocation failure occurs due to fragmentation, an application can:
create an additional descriptor pool to perform further descriptor set
allocations.
include::../validity/structs/VkDescriptorPoolCreateInfo.txt[]
See Also
--------
elink:VkDescriptorPoolCreateFlags, slink:VkDescriptorPoolSize, elink:VkStructureType, flink:vkCreateDescriptorPool
Document Notes
--------------
For more information, see the Vulkan Specification at URL
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#VkDescriptorPoolCreateInfo
This page is extracted from the Vulkan Specification.
Fixes and changes should be made to the Specification,not directly.
include::footer.txt[]