Fix random name markup
- add missing `*name` and `*link` and `code` - change where wrong macro was used - swap `*name` and `*link` where appropriate - correct misspelled names - that sort of thing...
This commit is contained in:
Petr Kraus
parent
c0f5633c7f
commit
d0eb98eb89
|
|
@ -215,7 +215,7 @@ Other Issues:
|
|||
* Add missing buffer usage requirements for indirect draws in
|
||||
flink:vkCmdDrawIndirect, flink:vkCmdDrawIndirectCountAMD,
|
||||
flink:vkCmdDrawIndexedIndirect, and
|
||||
flink:vlCmdDrawIndexedIndirectCountAMD.
|
||||
flink:vkCmdDrawIndexedIndirectCountAMD.
|
||||
* Modify Makefile to allow specification to build in git "`detached HEAD`"
|
||||
state.
|
||||
* Update valid usage ID generation script to allow recursively operating
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ compressed multisampled color surfaces.
|
|||
The fragment mask is a lookup table that associates color samples with color
|
||||
fragment values.
|
||||
|
||||
The fragment mask can be fetched with a call to pname:fragmentMaskFetchAMD
|
||||
from a shader, which returns a single uint where each subsequent 4 bit
|
||||
The fragment mask can be fetched with a call to code:fragmentMaskFetchAMD
|
||||
from a shader, which returns a single code:uint where each subsequent 4 bit
|
||||
specifies the color fragment index corresponding to the color sample,
|
||||
starting from the least significant bit.
|
||||
For example, when 8 color samples are used, the color fragment index for
|
||||
|
|
@ -27,7 +27,7 @@ color sample 0 will be in bits 0-3 of the fragment mask, for color sample 7
|
|||
the index will be in bits 28-31.
|
||||
|
||||
The color fragment for a particular color sample may then be fetched with
|
||||
the correspoding fragment mask value using the pname:fragmentFetchAMD shader
|
||||
the correspoding fragment mask value using the code:fragmentFetchAMD shader
|
||||
function.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ function parameters? If so, which functions?
|
|||
|
||||
*RESOLVED*: Yes.
|
||||
All functions have been modified to take a structure type with extensible
|
||||
pNext pointer, to allow future extensions to add additional annotation
|
||||
pname:pNext pointer, to allow future extensions to add additional annotation
|
||||
information in the same commands.
|
||||
|
||||
=== Version History
|
||||
|
|
|
|||
|
|
@ -141,8 +141,8 @@ The older enum is still available for backwards compatibility.
|
|||
|
||||
=== Issues
|
||||
|
||||
1) What is the hierarchy / seriousness of the message flags? E.g. ERROR >
|
||||
WARN > PERF_WARN ...
|
||||
1) What is the hierarchy / seriousness of the message flags? E.g.
|
||||
etext:ERROR > etext:WARN > etext:PERF_WARN ...
|
||||
|
||||
*RESOLVED*: There is no specific hierarchy.
|
||||
Each bit is independent and should be checked via bitwise AND.
|
||||
|
|
@ -158,9 +158,9 @@ For example:
|
|||
}
|
||||
----------------------------------------
|
||||
|
||||
The validation layers do use them in a hierarchical way (ERROR > WARN >
|
||||
PERF, WARN > DEBUG > INFO) and they (at least at the time of this writing)
|
||||
only set one bit at a time.
|
||||
The validation layers do use them in a hierarchical way (etext:ERROR >
|
||||
etext:WARN > etext:PERF, etext:WARN > etext:DEBUG > etext:INFO) and they (at
|
||||
least at the time of this writing) only set one bit at a time.
|
||||
But it is not a requirement of this extension.
|
||||
|
||||
It is possible that a layer may intercept and change, or augment the flags
|
||||
|
|
@ -168,7 +168,7 @@ with extension values the application's debug report handler may not be
|
|||
familiar with so it is important to treat each flag independently.
|
||||
|
||||
2) Should there be a VU requiring
|
||||
sname:VkDebugReportCallbackCreateInfoEXT::pname:flags to be non-zero?
|
||||
slink:VkDebugReportCallbackCreateInfoEXT::pname:flags to be non-zero?
|
||||
|
||||
*RESOLVED*: It may not be very useful, but we do not need VU statement
|
||||
requiring the sname:VkDebugReportCallbackCreateInfoEXT::pname:msgFlags at
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ In some cases it may be useful to extend this concept to a system-wide
|
|||
scope.
|
||||
This extension provides a mechanism for caller's to set their system-wide
|
||||
priority.
|
||||
The default queue priority is elink:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM.
|
||||
The default queue priority is ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM.
|
||||
|
||||
The driver implementation will attempt to skew hardware resource allocation
|
||||
in favour of the higher-priority task.
|
||||
|
|
@ -29,14 +29,14 @@ per-process queue priority
|
|||
Abuse of this feature may result in starving the rest of the system from
|
||||
hardware resources.
|
||||
Therefore, the driver implementation may deny requests to acquire a priority
|
||||
above the default priority (elink:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM) if the
|
||||
above the default priority (ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM) if the
|
||||
caller does not have sufficient privileges.
|
||||
In this scenario elink:VK_ERROR_NOT_PERMITTED_EXT is returned.
|
||||
In this scenario ename:VK_ERROR_NOT_PERMITTED_EXT is returned.
|
||||
|
||||
The driver implementation may fail the queue allocation request if resources
|
||||
required to complete the operation have been exhausted (either by the same
|
||||
process or a different process).
|
||||
In this scenario elink:VK_ERROR_INITIALIZATION_FAILED is returned.
|
||||
In this scenario ename:VK_ERROR_INITIALIZATION_FAILED is returned.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
@ -45,10 +45,10 @@ None.
|
|||
=== New Enum Constants
|
||||
|
||||
* Extending elink:VkStructureType:
|
||||
** elink:VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT
|
||||
** ename:VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT
|
||||
|
||||
* Extending elink:VkResult:
|
||||
** elink:VK_ERROR_NOT_PERMITTED_EXT
|
||||
** ename:VK_ERROR_NOT_PERMITTED_EXT
|
||||
|
||||
=== New Enums
|
||||
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ display pipeline to know the color volume of the original mastering display
|
|||
where content was created or tuned.
|
||||
This avoids performing unnecessary mapping of colors that are not
|
||||
displayable on the original mastering display.
|
||||
The metadata also includes the maxContentLightLevel and
|
||||
maxFrameAverageLightLevel as defined by CTA 861.3.
|
||||
The metadata also includes the pname:maxContentLightLevel and
|
||||
pname:maxFrameAverageLightLevel as defined by CTA 861.3.
|
||||
|
||||
While the general purpose of the metadata is to assist in the transformation
|
||||
between different color volumes of different displays and help achieve
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ automatic layout transition has to take place.
|
|||
slink:VkSampleLocationsInfoEXT can: be chained from
|
||||
slink:VkImageMemoryBarrier structures to provide sample locations for layout
|
||||
transitions performed by flink:vkCmdWaitEvents and
|
||||
flink:VkCmdPipelineBarrier calls, and
|
||||
flink:vkCmdPipelineBarrier calls, and
|
||||
slink:VkRenderPassSampleLocationsBeginInfoEXT can: be chained from
|
||||
slink:VkRenderPassBeginInfo to provide sample locations for layout
|
||||
transitions performed implicitly by a render pass instance.
|
||||
|
|
|
|||
|
|
@ -53,16 +53,16 @@ When using GLSL source-based shader languages, the following variables and
|
|||
shader functions from GL_ARB_shader_ballot can map to these SPIR-V built-in
|
||||
decorations and instructions:
|
||||
|
||||
* in uint64_t gl_SubGroupEqMaskARB; -> code:SubgroupEqMaskKHR,
|
||||
* in uint64_t gl_SubGroupGeMaskARB; -> code:SubgroupGeMaskKHR,
|
||||
* in uint64_t gl_SubGroupGtMaskARB; -> code:SubgroupGtMaskKHR,
|
||||
* in uint64_t gl_SubGroupLeMaskARB; -> code:SubgroupLeMaskKHR,
|
||||
* in uint64_t gl_SubGroupLtMaskARB; -> code:SubgroupLtMaskKHR,
|
||||
* in uint gl_SubGroupInvocationARB; -> code:SubgroupLocalInvocationId,
|
||||
* uniform uint gl_SubGroupSizeARB; -> code:SubgroupSize,
|
||||
* ballotARB() -> code:OpSubgroupBallotKHR,
|
||||
* readFirstInvocationARB() -> code:OpSubgroupFirstInvocationKHR, and
|
||||
* readInvocationARB() -> code:OpSubgroupReadInvocationKHR.
|
||||
* `in uint64_t gl_SubGroupEqMaskARB;` -> code:SubgroupEqMaskKHR,
|
||||
* `in uint64_t gl_SubGroupGeMaskARB;` -> code:SubgroupGeMaskKHR,
|
||||
* `in uint64_t gl_SubGroupGtMaskARB;` -> code:SubgroupGtMaskKHR,
|
||||
* `in uint64_t gl_SubGroupLeMaskARB;` -> code:SubgroupLeMaskKHR,
|
||||
* `in uint64_t gl_SubGroupLtMaskARB;` -> code:SubgroupLtMaskKHR,
|
||||
* `in uint gl_SubGroupInvocationARB;` -> code:SubgroupLocalInvocationId,
|
||||
* `uniform uint gl_SubGroupSizeARB;` -> code:SubgroupSize,
|
||||
* code:ballotARB() -> code:OpSubgroupBallotKHR,
|
||||
* code:readFirstInvocationARB() -> code:OpSubgroupFirstInvocationKHR, and
|
||||
* code:readInvocationARB() -> code:OpSubgroupReadInvocationKHR.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
|
|||
|
|
@ -64,8 +64,8 @@ where code:condition diverges between invocations, an implementation might
|
|||
first execute code:do_fast_path() for the invocations where code:condition
|
||||
is true and leave the other invocations dormant.
|
||||
Once code:do_fast_path() returns, it might call code:do_general_path() for
|
||||
invocations where code:condition is false and leave the other invocations
|
||||
dormant.
|
||||
invocations where code:condition is code:false and leave the other
|
||||
invocations dormant.
|
||||
In this case, the shader executes *both* the fast and the general path and
|
||||
might be better off just using the general path for all invocations.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ The code:ANativeWindow represents the producer endpoint of any buffer queue,
|
|||
regardless of consumer endpoint.
|
||||
Common consumer endpoints for code:ANativeWindows are the system window
|
||||
compositor, video encoders, and application-specific compositors importing
|
||||
the images through a SurfaceTexture.
|
||||
the images through a code:SurfaceTexture.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Further, these properties may be implemented on a per-display or per-overlay
|
|||
granularity.
|
||||
|
||||
To avoid the exponential growth of modes as mutable properties are added, as
|
||||
was the case with EGLConfig/WGL pixel formats/GLXFBConfig, this
|
||||
was the case with code:EGLConfig/WGL pixel formats/code:GLXFBConfig, this
|
||||
specification should separate out hardware properties and configurable state
|
||||
into separate objects.
|
||||
Modes and overlay planes will express capabilities of the hardware, while a
|
||||
|
|
@ -135,12 +135,13 @@ can a display mode + display be used alone to target an output?
|
|||
|
||||
*PROPOSED RESOLUTION*: Require specifying a plane explicitly.
|
||||
|
||||
9) Should displays have an associated window system display, such as an HDC
|
||||
or Display*?
|
||||
9) Should displays have an associated window system display, such as an
|
||||
code:HDC or code:Display*?
|
||||
|
||||
*PROPOSED RESOLUTION*: No.
|
||||
Displays are independent of any windowing system in use on the system.
|
||||
Further, neither HDC nor Display* refer to a physical display object.
|
||||
Further, neither code:HDC nor code:Display* refer to a physical display
|
||||
object.
|
||||
|
||||
10) Are displays queried from a physical GPU or from a device instance?
|
||||
|
||||
|
|
@ -205,7 +206,7 @@ displays? If so, how?
|
|||
|
||||
*RESOLVED*: Yes.
|
||||
Applications can determine which displays a given plane supports using
|
||||
vkGetDisplayPlaneSupportedDisplaysKHR.
|
||||
flink:vkGetDisplayPlaneSupportedDisplaysKHR.
|
||||
|
||||
17) Should there be a way to destroy display modes? If so, does it support
|
||||
destroying "`built in`" modes?
|
||||
|
|
|
|||
|
|
@ -48,15 +48,15 @@ an order that avoids the need for reference counting?
|
|||
*RESOLVED*: Take a reference.
|
||||
The lifetime of presentable images is already complex enough.
|
||||
|
||||
2) Should the srcRect/dstRect parameters be specified as part of the present
|
||||
command, or at swapchain creation time?
|
||||
2) Should the pname:srcRect/pname:dstRect parameters be specified as part of
|
||||
the present command, or at swapchain creation time?
|
||||
|
||||
*RESOLVED*: As part of the presentation command.
|
||||
This allows moving and scaling the image on the screen without the need to
|
||||
respecify the mode or create a new swapchain and presentable images.
|
||||
|
||||
3) Should srcRect/dstRect be specified as rects, or separate offset/extent
|
||||
values?
|
||||
3) Should pname:srcRect/pname:dstRect be specified as rects, or separate
|
||||
offset/extent values?
|
||||
|
||||
*RESOLVED*: As rects.
|
||||
Specifying them separately might make it easier for hardware to expose
|
||||
|
|
@ -76,8 +76,8 @@ pointed to a different structure, which had both an pname:sType/pname:pNext
|
|||
for additional extensions, and also had a pointer to the next
|
||||
slink:VkSwapchainCreateInfoKHR structure.
|
||||
The number of swapchains to be created could only be found by walking this
|
||||
linked list of alternating structures, and the pSwapchains out parameter was
|
||||
reinterpreted to be an array of slink:VkSwapchainKHR handles.
|
||||
linked list of alternating structures, and the pname:pSwapchains out
|
||||
parameter was reinterpreted to be an array of slink:VkSwapchainKHR handles.
|
||||
|
||||
Another option considered was a method to specify a "`shared`" swapchain
|
||||
when creating a new swapchain, such that groups of swapchains using the same
|
||||
|
|
@ -132,7 +132,7 @@ https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/dem
|
|||
- Updated sample code based on the changes to VK_KHR_swapchain.
|
||||
|
||||
* Revision 9, 2015-11-10 (Jesse Hall)
|
||||
- Replaced ftext:VkDisplaySwapchainCreateInfoKHR with
|
||||
- Replaced VkDisplaySwapchainCreateInfoKHR with
|
||||
vkCreateSharedSwapchainsKHR, changing resolution of issue #4.
|
||||
|
||||
* Revision 10, 2017-03-13 (James Jones)
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ transitioning memory between address spaces, and other APIs, instances, or
|
|||
processes may operate in a separate address space.
|
||||
Options for defining this transition include:
|
||||
|
||||
* A new structure that can be added to the pNext list in
|
||||
* A new structure that can be added to the pname:pNext list in
|
||||
slink:VkMemoryBarrier, slink:VkBufferMemoryBarrier, and
|
||||
slink:VkImageMemoryBarrier.
|
||||
* A new bit in elink:VkAccessFlags that can be set to indicate an
|
||||
|
|
@ -130,29 +130,32 @@ over-engineered solution.
|
|||
The access flag bit has the advantage that it can be applied at buffer,
|
||||
image, or global granularity, and semantically it maps pretty well to the
|
||||
operation being described.
|
||||
Additionally, the API already includes VK_ACCESS_MEMORY_READ_BIT and
|
||||
VK_ACCESS_MEMORY_WRITE_BIT which appear to be intended for this purpose.
|
||||
Additionally, the API already includes ename:VK_ACCESS_MEMORY_READ_BIT and
|
||||
ename:VK_ACCESS_MEMORY_WRITE_BIT which appear to be intended for this
|
||||
purpose.
|
||||
However, there is no obvious pipeline stage that would correspond to an
|
||||
external access, and therefore no clear way to use VK_ACCESS_MEMORY_READ_BIT
|
||||
or VK_ACCESS_MEMORY_WRITE_BIT.
|
||||
external access, and therefore no clear way to use
|
||||
ename:VK_ACCESS_MEMORY_READ_BIT or ename:VK_ACCESS_MEMORY_WRITE_BIT.
|
||||
elink:VkDependencyFlags and elink:VkPipelineStageFlags operate at command
|
||||
granularity rather than image or buffer granularity, which would make an
|
||||
entire pipeline barrier an internal->external or external->internal barrier.
|
||||
This may not be a problem in practice, but seems like the wrong scope.
|
||||
Another downside of elink:VkDependencyFlags is that it lacks inherent
|
||||
directionality: There are not src and dst variants of it in the barrier or
|
||||
dependency description semantics, so two bits might need to be added to
|
||||
describe both internal->external and external->internal transitions.
|
||||
directionality: There are not ptext:src and ptext:dst variants of it in the
|
||||
barrier or dependency description semantics, so two bits might need to be
|
||||
added to describe both internal->external and external->internal
|
||||
transitions.
|
||||
Transitioning a resource to a special queue family corresponds well with the
|
||||
operation of transitioning to a separate Vulkan instance, in that both
|
||||
operations ideally include scheduling a barrier on both sides of the
|
||||
transition: Both the releasing and the acquiring queue or process.
|
||||
Using a special queue family requires adding an additional reserved queue
|
||||
family index.
|
||||
Re-using VK_QUEUE_FAMILY_IGNORED would have left it unclear how to
|
||||
Re-using ename:VK_QUEUE_FAMILY_IGNORED would have left it unclear how to
|
||||
transition a concurrent usage resource from one process to another, since
|
||||
the semantics would have likely been equivalent to the currently-ignored
|
||||
transition of VK_QUEUE_FAMILY_IGNORED -> VK_QUEUE_FAMILY_IGNORED.
|
||||
transition of
|
||||
ename:VK_QUEUE_FAMILY_IGNORED{nbsp}->{nbsp}ename:VK_QUEUE_FAMILY_IGNORED.
|
||||
Fortunately, creating a new reserved queue family index is not invasive.
|
||||
|
||||
Based on the above analysis, the approach of transitioning to a special
|
||||
|
|
|
|||
|
|
@ -50,8 +50,8 @@ None.
|
|||
|
||||
=== Issues
|
||||
|
||||
1) Do applications need to call CloseHandle() on the values returned from
|
||||
flink:vkGetMemoryWin32HandleKHR when pname:handleType is
|
||||
1) Do applications need to call code:CloseHandle() on the values returned
|
||||
from flink:vkGetMemoryWin32HandleKHR when pname:handleType is
|
||||
ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR?
|
||||
|
||||
ifdef::editing-notes[]
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ Applications will be allowed to provide similar attributes to those they
|
|||
would to any other handle creation API.
|
||||
|
||||
4) How do applications communicate the desired fence values to use with
|
||||
D3D12_FENCE-based Vulkan semaphores?
|
||||
etext:D3D12_FENCE-based Vulkan semaphores?
|
||||
|
||||
*RESOLVED*: There are a couple of options.
|
||||
The values for the signaled and reset states could be communicated up front
|
||||
|
|
|
|||
|
|
@ -16,9 +16,10 @@ include::meta/VK_KHR_get_memory_requirements2.txt[]
|
|||
This extension provides new entry points to query memory requirements of
|
||||
images and buffers in a way that can be easily extended by other extensions,
|
||||
without introducing any further entry points.
|
||||
The Vulkan 1.0 VkMemoryRequirements and VkSparseImageMemoryRequirements
|
||||
structures do not include an sType/pNext, this extension wraps them in new
|
||||
structures with sType/pNext so an application can query a chain of memory
|
||||
The Vulkan 1.0 slink:VkMemoryRequirements and
|
||||
slink:VkSparseImageMemoryRequirements structures do not include a
|
||||
pname:sType/pname:pNext, this extension wraps them in new structures with
|
||||
pname:sType/pname:pNext so an application can query a chain of memory
|
||||
requirements structures by constructing the chain and letting the
|
||||
implementation fill them in.
|
||||
A new command is added for each ftext:vkGet*MemoryRequrements command in
|
||||
|
|
|
|||
|
|
@ -64,8 +64,9 @@ for each rectangle.
|
|||
One approach is to create another struct that contains the slink:VkRect2D
|
||||
plus layer, and have slink:VkPresentRegionsKHR point to an array of that
|
||||
struct.
|
||||
Another approach is to have two parallel arrays, pRectangles and pLayers,
|
||||
where pRectangles[i] and pLayers[i] must be used together.
|
||||
Another approach is to have two parallel arrays, ptext:pRectangles and
|
||||
ptext:pLayers, where ptext:pRectangles[i] and ptext:pLayers[i] must be used
|
||||
together.
|
||||
Which approach should we use, and if the array of a new structure, what
|
||||
should that be called?
|
||||
|
||||
|
|
|
|||
|
|
@ -34,9 +34,9 @@ The new features are as follows:
|
|||
This extension allows copying from layers of a 2D array image to slices
|
||||
of a 3D image and vice versa.
|
||||
* Allow negative height to be specified in the
|
||||
slink::VkViewport::pname:height field to perform y-inversion of the
|
||||
clip-space to framebuffer-space transform.
|
||||
This allows apps to avoid having to use gl_Position.y = -gl_Position.y
|
||||
slink:VkViewport::pname:height field to perform y-inversion of
|
||||
the clip-space to framebuffer-space transform.
|
||||
This allows apps to avoid having to use `gl_Position.y = -gl_Position.y`
|
||||
in shaders also targeting other APIs.
|
||||
* Allow implementations to express support for doing just transfers and
|
||||
clears of image formats that they otherwise support no other format
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ The new features are as follows:
|
|||
|
||||
Input attachment specification allows an application to specify which aspect
|
||||
of a multi-aspect image (e.g. a combined depth stencil format) will be
|
||||
accessed via a subpassLoad operation.
|
||||
accessed via a code:subpassLoad operation.
|
||||
|
||||
On some implementations there may: be a performance penalty if the
|
||||
implementation does not know (at flink:vkCreateRenderPass time) which
|
||||
|
|
@ -90,8 +90,8 @@ None.
|
|||
|
||||
Consider the case where a render pass has two subpasses and two attachments.
|
||||
|
||||
Attachment 0 has the format VK_FORMAT_D24_UNORM_S8_UINT, attachment 1 has
|
||||
some color format.
|
||||
Attachment 0 has the format ename:VK_FORMAT_D24_UNORM_S8_UINT, attachment 1
|
||||
has some color format.
|
||||
|
||||
Subpass 0 writes to attachment 0, subpass 1 reads only the depth information
|
||||
from attachment 0 (using inputAttachmentRead) and writes to attachment 1.
|
||||
|
|
|
|||
|
|
@ -30,10 +30,10 @@ This extension adds support for the following SPIR-V extension in Vulkan:
|
|||
The extension provides access to three additional built-in shader variables
|
||||
in Vulkan:
|
||||
|
||||
* code:BaseInstance, which contains the firstInstance parameter passed to
|
||||
* code:BaseInstance, which contains the pname:firstInstance parameter passed to
|
||||
draw commands,
|
||||
* code:BaseVertex, which contains the firstVertex/vertexOffset parameter
|
||||
passed to draw commands, and
|
||||
* code:BaseVertex, which contains the pname:firstVertex/pname:vertexOffset
|
||||
parameter passed to draw commands, and
|
||||
* code:DrawIndex, which contains the index of the draw call currently
|
||||
being processed from an indirect draw call.
|
||||
|
||||
|
|
@ -41,9 +41,9 @@ When using GLSL source-based shader languages, the following variables from
|
|||
+GL_ARB_shader_draw_parameters+ can map to these SPIR-V built-in
|
||||
decorations:
|
||||
|
||||
* in int gl_BaseInstanceARB; -> code:BaseInstance,
|
||||
* in int gl_BaseVertexARB -> code:BaseVertex, and
|
||||
* in int gl_DrawIDARB; -> code:DrawIndex.
|
||||
* `in int gl_BaseInstanceARB;` -> code:BaseInstance,
|
||||
* `in int gl_BaseVertexARB;` -> code:BaseVertex, and
|
||||
* `in int gl_DrawIDARB;` -> code:DrawIndex.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
@ -85,16 +85,16 @@ drawing commands.
|
|||
In GL for +GL_ARB_shader_draw_parameters+, code:gl_BaseVertexARB holds the
|
||||
integer value passed to the parameter to the command that resulted in the
|
||||
current shader invocation.
|
||||
In the case where the command has no baseVertex parameter, the value of
|
||||
In the case where the command has no code:baseVertex parameter, the value of
|
||||
code:gl_BaseVertexARB is zero.
|
||||
This means that code:gl_BaseVertexARB = baseVertex (for code:glDrawElements
|
||||
commands with baseVertex) or 0.
|
||||
In particular there are no code:glDrawArrays commands that take a baseVertex
|
||||
parameter.
|
||||
This means that code:gl_BaseVertexARB = code:baseVertex (for code:glDrawElements
|
||||
commands with code:baseVertex) or 0.
|
||||
In particular there are no code:glDrawArrays commands that take a
|
||||
code:baseVertex parameter.
|
||||
|
||||
Now in Vulkan, we have *BaseVertex* = _vertexOffset_ (for indexed drawing
|
||||
commands) or _firstVertex_ (for arrayed drawing commands), and so Vulkan's
|
||||
version is really a superset of GL functionality.
|
||||
Now in Vulkan, we have code:BaseVertex = pname:vertexOffset (for indexed
|
||||
drawing commands) or pname:firstVertex (for arrayed drawing commands), and
|
||||
so Vulkan's version is really a superset of GL functionality.
|
||||
|
||||
=== Version History
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ refresh is triggered?
|
|||
This is done via which presentation modes a surface supports.
|
||||
|
||||
3) Should the object representing a shared presentable image be an extension
|
||||
of a VkSwapchainKHR or a separate object?
|
||||
of a slink:VkSwapchainKHR or a separate object?
|
||||
|
||||
*RESOLVED*: Extension of a swapchain due to overlap in creation properties
|
||||
and to allow common functionality between shared and normal presentable
|
||||
|
|
@ -88,36 +88,39 @@ images and swapchains.
|
|||
|
||||
*RESOLVED*: Shared presentable image / shared present.
|
||||
|
||||
5) Should the minImageCount and presentMode values of the
|
||||
VkSwapchainCreateInfoKHR be ignored, or required to be compatible values?
|
||||
5) Should the pname:minImageCount and pname:presentMode values of the
|
||||
slink:VkSwapchainCreateInfoKHR be ignored, or required to be compatible
|
||||
values?
|
||||
|
||||
*RESOLVED*: minImageCount must be set to 1, and presentMode should be set to
|
||||
either VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or
|
||||
VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR.
|
||||
*RESOLVED*: pname:minImageCount must be set to 1, and pname:presentMode
|
||||
should be set to either ename:VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or
|
||||
ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR.
|
||||
|
||||
6) What should the layout of the shared presentable image be?
|
||||
|
||||
*RESOLVED*: After acquiring the shared presentable image, the application
|
||||
must transition it to the VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout prior to
|
||||
it being used.
|
||||
must transition it to the ename:VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout
|
||||
prior to it being used.
|
||||
After this intial transition, any image usage that was requested during
|
||||
swapchain creation can: be performed on the image without layout transitions
|
||||
being performed.
|
||||
|
||||
7) Do we need a new API for the trigger to refresh new content?
|
||||
|
||||
*RESOLVED*: vkQueuePresentKHR to act as API to trigger a refresh, as will
|
||||
allow combination with other compatible extensions to vkQueuePresentKHR.
|
||||
*RESOLVED*: flink:vkQueuePresentKHR to act as API to trigger a refresh, as
|
||||
will allow combination with other compatible extensions to
|
||||
flink:vkQueuePresentKHR.
|
||||
|
||||
8) How should an application detect a VK_ERROR_OUT_OF_DATE_KHR error on a
|
||||
swapchain using the VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR present
|
||||
mode?
|
||||
8) How should an application detect a ename:VK_ERROR_OUT_OF_DATE_KHR error
|
||||
on a swapchain using the ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
|
||||
present mode?
|
||||
|
||||
*RESOLVED*: Introduce vkGetSwapchainStatusKHR to allow applications to query
|
||||
the status of a swapchain using a shared presentation mode.
|
||||
*RESOLVED*: Introduce flink:vkGetSwapchainStatusKHR to allow applications to
|
||||
query the status of a swapchain using a shared presentation mode.
|
||||
|
||||
9) What should subsequent calls to vkQueuePresentKHR for CONTINUOUS_REFRESH
|
||||
swapchains be defined to do?
|
||||
9) What should subsequent calls to flink:vkQueuePresentKHR for
|
||||
ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to
|
||||
do?
|
||||
|
||||
*RESOLVED*: State that implementations may use it as a hint for updated
|
||||
content.
|
||||
|
|
@ -127,14 +130,14 @@ different queue?
|
|||
|
||||
*RESOLVED*: No.
|
||||
It is not possible to transfer ownership of a shared presentable image
|
||||
obtained from a swapchain created using VK_SHARING_MODE_EXCLUSIVE after it
|
||||
has been presented.
|
||||
obtained from a swapchain created using ename:VK_SHARING_MODE_EXCLUSIVE
|
||||
after it has been presented.
|
||||
|
||||
11) How should vkQueueSubmit behave if a command buffer uses an image from
|
||||
an OUT_OF_DATE swapchain?
|
||||
11) How should flink:vkQueueSubmit behave if a command buffer uses an image
|
||||
from an ename:VK_ERROR_OUT_OF_DATE_KHR swapchain?
|
||||
|
||||
*RESOLVED*: vkQueueSubmit is expected to return the VK_ERROR_DEVICE_LOST
|
||||
error.
|
||||
*RESOLVED*: flink:vkQueueSubmit is expected to return the
|
||||
ename:VK_ERROR_DEVICE_LOST error.
|
||||
|
||||
12) Can Vulkan provide any guarantee on the order of rendering, to enable
|
||||
beam chasing?
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This extension adds support for the following SPIR-V extension in Vulkan:
|
|||
|
||||
This extension provides a new SPIR-V code:StorageBuffer storage class.
|
||||
A code:Block-decorated object in this class is equivalent to a
|
||||
code:BufferBlock-decorated object in the *Uniform* storage class.
|
||||
code:BufferBlock-decorated object in the code:Uniform storage class.
|
||||
|
||||
=== New Enum Constants
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ presentation.
|
|||
|
||||
*RESOLVED*: Yes.
|
||||
The number of views associated with a presentable image is determined by the
|
||||
imageArraySize specified when creating a swapchain.
|
||||
pname:imageArrayLayers specified when creating a swapchain.
|
||||
All presentable images in a given swapchain use the same array size.
|
||||
|
||||
5) Are the layers of stereo presentable images half-sized?
|
||||
|
|
@ -117,13 +117,13 @@ execution of any commands using the image.
|
|||
|
||||
*RESOLVED*: The command takes a timeout parameter.
|
||||
Special values for the timeout are 0, which makes the call a non-blocking
|
||||
operation, and UINT64_MAX, which blocks indefinitely.
|
||||
operation, and code:UINT64_MAX, which blocks indefinitely.
|
||||
Values in between will block for up to the specified time.
|
||||
The call will return when an image becomes available or an error occurs.
|
||||
It may, but is not required to, return before the specified timeout expires
|
||||
if the swapchain becomes out of date.
|
||||
|
||||
8) Can multiple presents be queued using one QueuePresent call?
|
||||
8) Can multiple presents be queued using one flink:vkQueuePresentKHR call?
|
||||
|
||||
*RESOLVED*: Yes.
|
||||
slink:VkPresentInfoKHR contains a list of swapchains and corresponding image
|
||||
|
|
@ -188,7 +188,7 @@ as per-present parameters needs to be decided as well.
|
|||
- FIFO queue: Waits for the next vertical blanking period to update the
|
||||
current image.
|
||||
No tearing should be observed.
|
||||
An internal queue containing [eq]#pname:numSwapchainImages - 1# entries
|
||||
An internal queue containing [eq]#ptext:numSwapchainImages - 1# entries
|
||||
is used to hold pending presentation requests.
|
||||
New requests are appended to the end of the queue, and one request is
|
||||
removed from the beginning of the queue and processed during each
|
||||
|
|
@ -278,9 +278,9 @@ surfaces as part of presentation, and which is presenting to a surface that
|
|||
is displayed with a 90-degree rotation, would return only one supported
|
||||
transform bit: ename:VK_SURFACE_TRANSFORM_ROT90_BIT_KHR.
|
||||
Applications must transform their rendering by the transform they specify
|
||||
when creating the swapchain in preTransform field.
|
||||
when creating the swapchain in pname:preTransform field.
|
||||
|
||||
18) Can surfaces ever not support ename:VK_MIRROR_NONE? Can they support
|
||||
18) Can surfaces ever not support etext:VK_MIRROR_NONE? Can they support
|
||||
vertical and horizontal mirroring simultaneously? Relatedly, should
|
||||
etext:VK_MIRROR_NONE[_BIT] be zero, or bit one, and should applications be
|
||||
allowed to specify multiple pre and current mirror transform bits, or
|
||||
|
|
@ -295,13 +295,13 @@ To allow this, the etext:MIRROR_NONE enum must occupy a bit in the flags.
|
|||
Since etext:MIRROR_NONE must be a bit in the bitmask rather than a bitmask
|
||||
with no values set, allowing more than one bit to be set in the bitmask
|
||||
would make it possible to describe undefined transforms such as
|
||||
ename:VK_MIRROR_NONE_BIT | ename:VK_MIRROR_HORIZONTAL_BIT, or a transform
|
||||
etext:VK_MIRROR_NONE_BIT | etext:VK_MIRROR_HORIZONTAL_BIT, or a transform
|
||||
that includes both "`no mirroring`" and "`horizontal mirroring
|
||||
simultaneously.
|
||||
Therefore, it is desirable to allow specifying all supported mirroring
|
||||
transforms using only one bit.
|
||||
The question then becomes, should there be a
|
||||
ename:VK_MIRROR_HORIZONTAL_AND_VERTICAL_BIT to represent a simultaneous
|
||||
etext:VK_MIRROR_HORIZONTAL_AND_VERTICAL_BIT to represent a simultaneous
|
||||
horizontal and vertical mirror transform? However, such a transform is
|
||||
equivalent to a 180 degree rotation, so presentation engines and
|
||||
applications that wish to support or use such a transform can express it
|
||||
|
|
@ -342,7 +342,7 @@ using a Vulkan swapchain, the application can set the pretransform to
|
|||
none are available, a platform-specific default will be used.
|
||||
Platforms that do not specify a reasonable default or do not provide native
|
||||
mechanisms to specify such transforms should not include the inherit bits in
|
||||
the supportedTransform bitmask they return in
|
||||
the pname:supportedTransforms bitmask they return in
|
||||
slink:VkSurfaceCapabilitiesKHR.
|
||||
|
||||
22) Should the content of presentable images be clipped by objects obscuring
|
||||
|
|
@ -378,11 +378,11 @@ such formats does not guarantee working in a specific color space.
|
|||
It merely means that the hardware can directly support applying the
|
||||
non-linear transfer functions defined by the sRGB standard color space when
|
||||
reading from or writing to images of that these formats.
|
||||
Still, it is unlikely that a swapchain will expose a _SRGB format along with
|
||||
any color space other than ename:VK_COLOR_SPACE_SRGB_NONLINEAR.
|
||||
Still, it is unlikely that a swapchain will expose a etext:*_SRGB format
|
||||
along with any color space other than ename:VK_COLOR_SPACE_SRGB_NONLINEAR.
|
||||
|
||||
On the other hand, non-_SRGB formats will be very likely exposed in pair
|
||||
with a SRGB color space.
|
||||
On the other hand, non-etext:*_SRGB formats will be very likely exposed in
|
||||
pair with a SRGB color space.
|
||||
This means, the hardware will not apply any transfer function when reading
|
||||
from or writing to such images, yet they will still be presented on a device
|
||||
with sRGB display characteristics.
|
||||
|
|
@ -402,7 +402,8 @@ images is treated by the presentation engine during compositing?
|
|||
with the presentation engine on how to treat image alpha values during the
|
||||
compositing process.
|
||||
Since not all platforms can practically control this through the Vulkan
|
||||
driver, a value of INHERIT is provided like for surface transforms.
|
||||
driver, a value of ename:VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR is provided like
|
||||
for surface transforms.
|
||||
|
||||
27) Is flink:vkCreateSwapchainKHR the right function to return
|
||||
ename:VK_ERROR_NATIVE_WINDOW_IN_USE_KHR, or should the various
|
||||
|
|
|
|||
|
|
@ -30,9 +30,9 @@ pointers into uniform and/or storage buffers, where the pointer values can
|
|||
be dynamic and non-uniform.
|
||||
|
||||
The +SPV_KHR_variable_pointers+ extension introduces two capabilities.
|
||||
The first, +VariablePointersStorageBuffer+, must: be supported by all
|
||||
The first, code:VariablePointersStorageBuffer, must: be supported by all
|
||||
implementations of this extension.
|
||||
The second, +VariablePointers+, is optional.
|
||||
The second, code:VariablePointers, is optional.
|
||||
|
||||
=== New Enum Constants
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ The second, +VariablePointers+, is optional.
|
|||
=== Issues
|
||||
|
||||
1) Do we need an optional property for the SPIR-V
|
||||
+VariablePointersStorageBuffer+ capability or should it be mandatory when
|
||||
code:VariablePointersStorageBuffer capability or should it be mandatory when
|
||||
this extension is advertised?
|
||||
|
||||
*RESOLVED*: Add it as a distinct feature, but make support mandatory.
|
||||
|
|
|
|||
|
|
@ -58,8 +58,8 @@ None
|
|||
1) Does Wayland need a way to query for compatibility between a particular
|
||||
physical device and a specific Wayland display? This would be a more general
|
||||
query than flink:vkGetPhysicalDeviceSurfaceSupportKHR: if the
|
||||
Wayland-specific query returned true for a (slink:VkPhysicalDevice, struct
|
||||
wl_display*) pair, then the physical device could be assumed to support
|
||||
Wayland-specific query returned ename:VK_TRUE for a (slink:VkPhysicalDevice,
|
||||
`struct wl_display*`) pair, then the physical device could be assumed to support
|
||||
presentation to any slink:VkSurfaceKHR for surfaces on the display.
|
||||
|
||||
*RESOLVED*: Yes.
|
||||
|
|
|
|||
|
|
@ -66,9 +66,9 @@ While it may be useful, there is not a clear way to do this on Win32.
|
|||
However, a method was added to query support for presenting to the windows
|
||||
desktop as a whole.
|
||||
|
||||
2) If a native window object (HWND) is used by one graphics API, and then is
|
||||
later used by a different graphics API (one of which is Vulkan), can these
|
||||
uses interfere with each other?
|
||||
2) If a native window object (code:HWND) is used by one graphics API, and
|
||||
then is later used by a different graphics API (one of which is Vulkan), can
|
||||
these uses interfere with each other?
|
||||
|
||||
*RESOLVED*: Yes.
|
||||
|
||||
|
|
@ -87,13 +87,13 @@ Potential failures include:
|
|||
object.
|
||||
|
||||
* Creating then destroying a slink:VkSwapchainKHR on a window object can
|
||||
effectively SetPixelFormat to a different format than the format chosen
|
||||
by an OpenGL application.
|
||||
effectively code:SetPixelFormat to a different format than the format
|
||||
chosen by an OpenGL application.
|
||||
|
||||
* Creating then destroying a slink:VkSwapchainKHR on a window object on one
|
||||
VkPhysicalDevice can prevent flink:vkCreateSwapchainKHR from succeeding
|
||||
on the same window object, but on a different VkPhysicalDevice that is
|
||||
associated with a different Vulkan ICD.
|
||||
slink:VkPhysicalDevice can prevent flink:vkCreateSwapchainKHR from
|
||||
succeeding on the same window object, but on a different
|
||||
slink:VkPhysicalDevice that is associated with a different Vulkan ICD.
|
||||
|
||||
In all cases the problem can be worked around by creating a new window
|
||||
object.
|
||||
|
|
@ -107,12 +107,12 @@ Technical details include:
|
|||
implementation to create a slink:VkSwapchainKHR over the same window
|
||||
object.
|
||||
Mention of this alteration can be found in the remarks section of the
|
||||
MSDN documentation for DXGI_SWAP_EFFECT.
|
||||
MSDN documentation for code:DXGI_SWAP_EFFECT.
|
||||
|
||||
* Calling GDI's SetPixelFormat (needed by OpenGL's WGL layer) on a window
|
||||
object alters the object for the remainder of its lifetime.
|
||||
The MSDN documentation for SetPixelFormat explains that a window object's
|
||||
pixel format can be set only one time.
|
||||
* Calling GDI's code:SetPixelFormat (needed by OpenGL's WGL layer) on a
|
||||
window object alters the object for the remainder of its lifetime.
|
||||
The MSDN documentation for code:SetPixelFormat explains that a window
|
||||
object's pixel format can be set only one time.
|
||||
|
||||
* Creating a slink:VkSwapchainKHR over a window object can alter the object
|
||||
for the remaining life of its lifetime.
|
||||
|
|
|
|||
|
|
@ -58,9 +58,9 @@ None
|
|||
|
||||
1) Does XCB need a way to query for compatibility between a particular
|
||||
physical device and a specific screen? This would be a more general query
|
||||
than flink:vkGetPhysicalDeviceSurfaceSupportKHR: If it returned true, then
|
||||
the physical device could be assumed to support presentation to any window
|
||||
on that screen.
|
||||
than flink:vkGetPhysicalDeviceSurfaceSupportKHR: If it returned
|
||||
ename:VK_TRUE, then the physical device could be assumed to support
|
||||
presentation to any window on that screen.
|
||||
|
||||
*RESOLVED*: Yes, this is needed for toolkits that want to create a
|
||||
slink:VkDevice before creating a window.
|
||||
|
|
|
|||
|
|
@ -58,9 +58,9 @@ None
|
|||
|
||||
1) Does X11 need a way to query for compatibility between a particular
|
||||
physical device and a specific screen? This would be a more general query
|
||||
than flink:vkGetPhysicalDeviceSurfaceSupportKHR : if it returned true, then
|
||||
the physical device could be assumed to support presentation to any window
|
||||
on that screen.
|
||||
than flink:vkGetPhysicalDeviceSurfaceSupportKHR : if it returned
|
||||
ename:VK_TRUE, then the physical device could be assumed to support
|
||||
presentation to any window on that screen.
|
||||
|
||||
*RESOLVED*: Yes, this is needed for toolkits that want to create a
|
||||
slink:VkDevice before creating a window.
|
||||
|
|
|
|||
|
|
@ -52,10 +52,10 @@ Why the discrepancy?
|
|||
|
||||
*RESOLVED*: It is for C compatibility.
|
||||
The definition for the VI native window handle type is defined inside the
|
||||
nn::vi C++ namespace.
|
||||
code:nn::code:vi C++ namespace.
|
||||
This prevents its use in C source files.
|
||||
nn::vi::NativeWindowHandle is always defined to be void*, so this
|
||||
extension uses void* to match.
|
||||
code:nn::code:vi::code:NativeWindowHandle is always defined to be
|
||||
code:void*, so this extension uses code:void* to match.
|
||||
|
||||
=== Version History
|
||||
|
||||
|
|
|
|||
|
|
@ -162,14 +162,14 @@ They also benefit from being processable in parallel.
|
|||
|
||||
3) How to name sequence description
|
||||
|
||||
ExecuteCommandSignature a bit long, just ExecuteSignature or actually more
|
||||
Vulkan nomenclature IndirectCommandsLayout
|
||||
stext:ExecuteCommandSignature a bit long, just stext:ExecuteSignature or
|
||||
actually more Vulkan nomenclature slink:VkIndirectCommandsLayoutNVX.
|
||||
|
||||
4) Do we want to provide indirectCommands inputs with layout or at
|
||||
indirectCommands time?
|
||||
4) Do we want to provide code:indirectCommands inputs with layout or at
|
||||
code:indirectCommands time?
|
||||
|
||||
Separate layout from data as Vulkan does.
|
||||
Provide full flexibilty for indirectCommands.
|
||||
Provide full flexibilty for code:indirectCommands.
|
||||
|
||||
5) Should the input be provided as SoA or AoS?
|
||||
|
||||
|
|
@ -189,8 +189,9 @@ pname:maxSequenceCount can give an upper estimate, even if the actual count
|
|||
is sourced from the gpu buffer at (buffer, countOffset).
|
||||
As such pname:maxSequenceCount must always be set correctly.
|
||||
|
||||
Developers are encouraged to make well use the IndirectCommandsLayout's
|
||||
pname:pTokens->divisor, as they allow less conservative storage costs.
|
||||
Developers are encouraged to make well use the
|
||||
slink:VkIndirectCommandsLayoutNVX's ptext:pTokens[].divisor, as they allow
|
||||
less conservative storage costs.
|
||||
Especially pipeline changes on a per-draw basis can be costly memory wise.
|
||||
|
||||
7) How to deal with dynamic offsets in DescriptorSets?
|
||||
|
|
@ -205,7 +206,7 @@ added dynamicCount field, variable sized input
|
|||
|
||||
Desired yes, people may change "`material`" shaders and not want to recreate
|
||||
the entire register table.
|
||||
However the developer must ensure to not overwrite a registered objectindex
|
||||
However the developer must ensure to not overwrite a registered objectIndex
|
||||
while it is still being used.
|
||||
|
||||
9) Should we allow dynamic state changes?
|
||||
|
|
@ -213,7 +214,8 @@ while it is still being used.
|
|||
Seems a bit excessive for "`per-draw`" type of scenario, but GPU could
|
||||
partition work itself with viewport/scissor...
|
||||
|
||||
10) How do we allow re-using already "`filled`" indirectCommands buffers?
|
||||
10) How do we allow re-using already "`filled`" code:indirectCommands
|
||||
buffers?
|
||||
|
||||
just use a slink:VkCommandBuffer for the output, and it can be reused
|
||||
easily.
|
||||
|
|
@ -232,20 +234,23 @@ in terms of internal device code generation is done.
|
|||
|
||||
Options:
|
||||
|
||||
a) on the host command buffer like a regular draw call b)
|
||||
flink:vkCmdProcessCommandsNVX makes use slink:VkCommandBufferBeginInfo
|
||||
and serves as flink:vkBeginCommandBuffer / flink:vkEndCommandBuffer
|
||||
implicitly.
|
||||
c) The targetCommandbuffer must be inside the "`begin`" state already at
|
||||
the moment of being passed.
|
||||
This very likely suggests a new slink:VkCommandBufferUsageFlags
|
||||
etext:VK_COMMAND_BUFFER_USAGE_DEVICE_GENERATED_BIT.
|
||||
d) The targetCommandbuffer must reserve space via a new function.
|
||||
a) on the host command buffer like a regular draw call
|
||||
|
||||
used a & d.
|
||||
b) flink:vkCmdProcessCommandsNVX makes use slink:VkCommandBufferBeginInfo
|
||||
and serves as flink:vkBeginCommandBuffer / flink:vkEndCommandBuffer
|
||||
implicitly.
|
||||
|
||||
c) The pname:targetCommandbuffer must be inside the "`begin`" state already
|
||||
at the moment of being passed.
|
||||
This very likely suggests a new slink:VkCommandBufferUsageFlags
|
||||
etext:VK_COMMAND_BUFFER_USAGE_DEVICE_GENERATED_BIT.
|
||||
|
||||
d) The pname:targetCommandbuffer must reserve space via a new function.
|
||||
|
||||
used a) and d).
|
||||
|
||||
14) What if different pipelines have different DescriptorSetLayouts at a
|
||||
certain set unit that mismatches in "`token.dynamicCount`"?
|
||||
certain set unit that mismatches in code:token.dynamicCount?
|
||||
|
||||
Considered legal, as long as the maximum dynamic count of all used
|
||||
DescriptorSetLayouts is provided.
|
||||
|
|
@ -292,7 +297,7 @@ follow up.
|
|||
Only distinguish between graphics/compute for now, further splitting up may
|
||||
lead to too much fractioning.
|
||||
|
||||
20) When can the objectTable be modified?
|
||||
20) When can the pname:objectTable be modified?
|
||||
|
||||
Similar to the other inputs for flink:vkCmdProcessCommandsNVX, only when all
|
||||
device access via flink:vkCmdProcessCommandsNVX or execution of target
|
||||
|
|
@ -321,7 +326,7 @@ ename:VK_ACCESS_COMMAND_PROCESS_READ_BIT_NVX and
|
|||
ename:VK_ACCESS_COMMAND_PROCESS_WRITE_BIT_NVX, used to synchronize reading
|
||||
the buffer inputs and writing the command buffer memory output.
|
||||
The output written in the target command buffer is considered to be consumed
|
||||
by the DRAW_INDIRECT pipeline stage.
|
||||
by the ename:VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT pipeline stage.
|
||||
|
||||
Thus, to synchronize from writing the input buffers to executing
|
||||
flink:vkCmdProcessCommandsNVX, use:
|
||||
|
|
|
|||
|
|
@ -35,10 +35,11 @@ between views in the X component.
|
|||
A subpass can declare via a second creation flag whether all pipelines
|
||||
compiled for this subpass will obey this restriction.
|
||||
|
||||
Shaders that use the new per-view outputs (e.g. gl_PositionPerViewNV) must:
|
||||
also write the non-per-view output (gl_Position), and the values written
|
||||
must: be such that gl_Position = gl_PositionPerViewNV[gl_ViewIndex] for all
|
||||
views in the subpass.
|
||||
Shaders that use the new per-view outputs (e.g. code:gl_PositionPerViewNV)
|
||||
must: also write the non-per-view output (code:gl_Position), and the values
|
||||
written must: be such that
|
||||
`gl_Position = gl_PositionPerViewNV[gl_ViewIndex]`
|
||||
for all views in the subpass.
|
||||
Implementations are free to either use the per-view outputs or the
|
||||
non-per-view outputs, whichever would be more efficient.
|
||||
|
||||
|
|
|
|||
|
|
@ -66,8 +66,8 @@ Other APIs will fall into two categories: Those that are Vulkan compatible
|
|||
(A term to be defined by subsequent interopability extensions), or Vulkan
|
||||
incompatible.
|
||||
When sharing images with Vulkan incompatible APIs, the Vulkan image must be
|
||||
transitioned to the GENERAL layout before handing it off to the external
|
||||
API.
|
||||
transitioned to the ename:VK_IMAGE_LAYOUT_GENERAL layout before handing it
|
||||
off to the external API.
|
||||
|
||||
Note this does not attempt to address cross-device transitions, nor
|
||||
transitions to engines on the same device which are not visible within the
|
||||
|
|
|
|||
|
|
@ -66,8 +66,8 @@ Other APIs will fall into two categories: Those that are Vulkan compatible
|
|||
(A term to be defined by subsequent interopability extensions), or Vulkan
|
||||
incompatible.
|
||||
When sharing images with Vulkan incompatible APIs, the Vulkan image must be
|
||||
transitioned to the GENERAL layout before handing it off to the external
|
||||
API.
|
||||
transitioned to the ename:VK_IMAGE_LAYOUT_GENERAL layout before handing it
|
||||
off to the external API.
|
||||
|
||||
Note this does not attempt to address cross-device transitions, nor
|
||||
transitions to engines on the same device which are not visible within the
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ include::meta/VK_NV_fill_rectangle.txt[]
|
|||
*Contributors*::
|
||||
- Jeff Bolz, NVIDIA
|
||||
|
||||
This extension adds a new elink:VkPolygonMode enum where a triangle is
|
||||
This extension adds a new elink:VkPolygonMode code:enum where a triangle is
|
||||
rasterized by computing and filling its axis-aligned screen-space bounding
|
||||
box, disregarding the actual triangle edges.
|
||||
This can be useful for drawing a rectangle without being split into two
|
||||
|
|
|
|||
|
|
@ -90,9 +90,9 @@ following table.
|
|||
[options="header"]
|
||||
|====
|
||||
| Input Layout | Implied Output Layout
|
||||
| points | layout(points, max_vertices=1)
|
||||
| lines | layout(line_stripo, max_vertices=2)
|
||||
| triangles | layout(triangle_strip, max_vertices=3)
|
||||
| points | `layout(points, max_vertices=1)`
|
||||
| lines | `layout(line_stripo, max_vertices=2)`
|
||||
| triangles | `layout(triangle_strip, max_vertices=3)`
|
||||
|====
|
||||
|
||||
2) How does interface matching work with passthrough geometry shaders?
|
||||
|
|
@ -105,7 +105,7 @@ In Vulkan all SPIR-V shader inputs (except built-ins) must also have
|
|||
location decorations specified.
|
||||
Redeclarations of built-in varables that add the passthrough layout
|
||||
qualifier are exempted from the rule requiring location assignment because
|
||||
built-in variables are do not have locations and are matched by builtin
|
||||
built-in variables are do not have locations and are matched by code:BuiltIn
|
||||
decoration.
|
||||
|
||||
|
||||
|
|
@ -141,11 +141,11 @@ void main()
|
|||
}
|
||||
---------------------------------------------------
|
||||
|
||||
In this shader, the inputs "gl_Position", "Inputs.texcoord", and
|
||||
"Inputs.baseColor" are simply copied from the input vertex to the
|
||||
In this shader, the inputs code:gl_Position, code:Inputs.texcoord, and
|
||||
code:Inputs.baseColor are simply copied from the input vertex to the
|
||||
corresponding output vertex.
|
||||
The only "interesting" work done by the geometry shader is computing and
|
||||
emitting a gl_Layer value for the primitive.
|
||||
emitting a code:gl_Layer value for the primitive.
|
||||
|
||||
The following geometry shader, using this extension, is equivalent:
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ multiple layers.
|
|||
A new shader built-in output code:ViewportMaskNV is provided, which allows a
|
||||
single primitive to be output to multiple viewports simultaneously.
|
||||
Also, a new SPIR-V decoration is added to control whether the effective
|
||||
viewport index is added into the variable decorated with the *Layer*
|
||||
viewport index is added into the variable decorated with the code:Layer
|
||||
built-in decoration.
|
||||
These capabilities allow a single primitive to be output to multiple layers
|
||||
simultaneously.
|
||||
|
|
|
|||
|
|
@ -163,28 +163,28 @@ separate viewport (numbered 0..5).
|
|||
Each face also has a separate swizzle, programmed via the
|
||||
slink:VkPipelineViewportSwizzleStateCreateInfoNV pipeline state.
|
||||
The viewport swizzle feature performs the coordinate transformation handled
|
||||
by the rotate() function in the original shader.
|
||||
The "viewport_relative" layout qualifier says that the viewport number
|
||||
(0..5) is added to the base gl_Layer value of zero to determine which layer
|
||||
(cube face) the primitive should be sent to.
|
||||
by the code:rotate() function in the original shader.
|
||||
The code:viewport_relative layout qualifier says that the viewport number
|
||||
(0..5) is added to the base code:gl_Layer value of 0 to determine which
|
||||
layer (cube face) the primitive should be sent to.
|
||||
|
||||
Note that the use of the passed through input <normal> in this example
|
||||
Note that the use of the passed through input code:normal in this example
|
||||
suggests that the fragment shader in this example would perform an operation
|
||||
like per-fragment lighting.
|
||||
The viewport swizzle would transform the position to be face-relative, but
|
||||
<normal> would remain in the original coordinate system.
|
||||
code:normal would remain in the original coordinate system.
|
||||
It seems likely that the fragment shader in either version of the example
|
||||
would want to perform lighting in the original coordinate system.
|
||||
It would likely do this by reconstructing the position of the fragment in
|
||||
the original coordinate system using gl_FragCoord, a constant or uniform
|
||||
holding the size of the cube face, and the input gl_ViewportIndex (or
|
||||
gl_Layer), which identifies the cube face.
|
||||
Since the value of <normal> is in the original coordinate system, it would
|
||||
not need to be modified as part of this coordinate transformation.
|
||||
the original coordinate system using code:gl_FragCoord, a constant or
|
||||
uniform holding the size of the cube face, and the input
|
||||
code:gl_ViewportIndex (or code:gl_Layer), which identifies the cube face.
|
||||
Since the value of code:normal is in the original coordinate system, it
|
||||
would not need to be modified as part of this coordinate transformation.
|
||||
|
||||
Note that while the rotate() operation in the regular geometry shader above
|
||||
could include an arbitrary post-rotation projection matrix, the viewport
|
||||
swizzle does not support arbitrary math.
|
||||
Note that while the code:rotate() operation in the regular geometry shader
|
||||
above could include an arbitrary post-rotation projection matrix, the
|
||||
viewport swizzle does not support arbitrary math.
|
||||
To get proper projection, [eq]#1/W# buffering should be used.
|
||||
To do this:
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ be [eq]#z'/w' = 1/Z~eye~#.
|
|||
2.
|
||||
On NVIDIA implementations supporting floating-point depth buffers with
|
||||
values outside [eq]#[0,1]#, prevent unwanted near plane clipping by enabling
|
||||
DEPTH_CLAMP.
|
||||
pname:depthClampEnable.
|
||||
Ensure that the depth clamp doesn't mess up depth testing by programming the
|
||||
depth range to very large values, such as [eq]#pname:minDepthBounds=-z#,
|
||||
[eq]#pname:maxDepthBounds=+z#, where [eq]#z = 2^127^#.
|
||||
|
|
@ -220,7 +220,7 @@ For example, if the near plane is at [eq]#Z~eye~ = 1/256#, scale [eq]#X#,
|
|||
Adjust depth testing to reflect the fact that [eq]#1/W# values are large
|
||||
near the eye and small away from the eye.
|
||||
Clear the depth buffer to zero (infinitely far away) and use a depth test of
|
||||
GREATER instead of LESS.
|
||||
ename:VK_COMPARE_OP_GREATER instead of ename:VK_COMPARE_OP_LESS.
|
||||
|
||||
|
||||
=== Version History
|
||||
|
|
|
|||
|
|
@ -355,11 +355,11 @@ typedef <return_type> (VKAPI_PTR *PFN_<command_name>)(<command_parameters>);
|
|||
|
||||
// @refBegin VK_NO_STDINT_H Control definition of +<stdint.h>+ types
|
||||
|
||||
If the +VK_NO_STDINT_H+ macro is defined by the application at compile time,
|
||||
extended integer types used by +vulkan.h+, such as code:uint8_t, must: also
|
||||
be defined by the application.
|
||||
Otherwise, +vulkan.h+ will not compile.
|
||||
If +VK_NO_STDINT_H+ is not defined, the system +<stdint.h>+ is used to
|
||||
If the dname:VK_NO_STDINT_H macro is defined by the application at compile
|
||||
time, extended integer types used by `vulkan.h`, such as code:uint8_t, must:
|
||||
also be defined by the application.
|
||||
Otherwise, `vulkan.h` will not compile.
|
||||
If dname:VK_NO_STDINT_H is not defined, the system `+<stdint.h>+` is used to
|
||||
define these types, or there is a fallback path when Microsoft Visual Studio
|
||||
version 2008 and earlier versions are detected at compile time.
|
||||
|
||||
|
|
@ -375,13 +375,13 @@ To use a Vulkan extension supporting a platform-specific window system,
|
|||
header files for that window systems must: be included at compile time.
|
||||
The Vulkan header files cannot determine whether or not an external header
|
||||
is available at compile time, so applications wishing to use such an
|
||||
extension must: #define a macro causing such headers to be included.
|
||||
extension must: `#define` a macro causing such headers to be included.
|
||||
If this is not done, the corresponding extension interfaces will not be
|
||||
defined and they will be unusable.
|
||||
|
||||
The extensions, required: compile time symbols to enable them, window
|
||||
systems they correspond to, and external header files that are included when
|
||||
the macro is #defined are shown in the
|
||||
the macro is ``#define``d are shown in the
|
||||
<<boilerplate-wsi-header-table,following table>>.
|
||||
|
||||
[[boilerplate-wsi-header-table]]
|
||||
|
|
@ -389,20 +389,20 @@ the macro is #defined are shown in the
|
|||
[options="header"]
|
||||
|====
|
||||
| Extension Name | Required Compile Time Symbol | Window System Name | External Header Files Used
|
||||
| +VK_KHR_android_surface+ | +VK_USE_PLATFORM_ANDROID_KHR+ | Android Native | +<android/native_window.h>+
|
||||
| +VK_KHR_mir_surface+ | +VK_USE_PLATFORM_MIR_KHR+ | Mir | +<mir_toolkit/client_types.h>+
|
||||
| +VK_KHR_wayland_surface+ | +VK_USE_PLATFORM_WAYLAND_KHR+ | Wayland | +<wayland-client.h>+
|
||||
| +VK_KHR_win32_surface+ | +VK_USE_PLATFORM_WIN32_KHR+ | Microsoft Windows | +<windows.h>+
|
||||
| +VK_KHR_xcb_surface+ | +VK_USE_PLATFORM_XCB_KHR+ | X Window System Xcb library | +<xcb/xcb.h>+
|
||||
| +VK_KHR_xlib_surface+ | +VK_USE_PLATFORM_XLIB_KHR+ | X Window System Xlib library | +<X11/Xlib.h>+
|
||||
| +VK_KHR_android_surface+ | dname:VK_USE_PLATFORM_ANDROID_KHR | Android Native | `+<android/native_window.h>+`
|
||||
| +VK_KHR_mir_surface+ | dname:VK_USE_PLATFORM_MIR_KHR | Mir | `+<mir_toolkit/client_types.h>+`
|
||||
| +VK_KHR_wayland_surface+ | dname:VK_USE_PLATFORM_WAYLAND_KHR | Wayland | `+<wayland-client.h>+`
|
||||
| +VK_KHR_win32_surface+ | dname:VK_USE_PLATFORM_WIN32_KHR | Microsoft Windows | `+<windows.h>+`
|
||||
| +VK_KHR_xcb_surface+ | dname:VK_USE_PLATFORM_XCB_KHR | X Window System Xcb library | `+<xcb/xcb.h>+`
|
||||
| +VK_KHR_xlib_surface+ | dname:VK_USE_PLATFORM_XLIB_KHR | X Window System Xlib library | `+<X11/Xlib.h>+`
|
||||
ifdef::VK_MVK_ios_surface[]
|
||||
| +VK_MVK_ios_surface+ | +VK_USE_PLATFORM_IOS_MVK+ | iOS | None
|
||||
| +VK_MVK_ios_surface+ | dname:VK_USE_PLATFORM_IOS_MVK | iOS | None
|
||||
endif::VK_MVK_ios_surface[]
|
||||
ifdef::VK_MVK_macos_surface[]
|
||||
| +VK_MVK_macos_surface+ | +VK_USE_PLATFORM_MACOS_MVK+ | macOS | None
|
||||
| +VK_MVK_macos_surface+ | dname:VK_USE_PLATFORM_MACOS_MVK | macOS | None
|
||||
endif::VK_MVK_macos_surface[]
|
||||
ifdef::VK_NN_vi_surface[]
|
||||
| +VK_NN_vi_surface+ | +VK_USE_PLATFORM_VI_NN+ | VI | None
|
||||
| +VK_NN_vi_surface+ | dname:VK_USE_PLATFORM_VI_NN | VI | None
|
||||
endif::VK_NN_vi_surface[]
|
||||
|====
|
||||
|
||||
|
|
|
|||
|
|
@ -849,7 +849,7 @@ Plane::
|
|||
Most images consist only of a single plane, but some formats spread the
|
||||
channels across multiple image planes.
|
||||
The host-accessible properties of each image plane are accessed in a
|
||||
linear layout using vkGetImageSubresourceLayout.
|
||||
linear layout using flink:vkGetImageSubresourceLayout.
|
||||
If a multi-planar image is created with the
|
||||
ename:VK_IMAGE_CREATE_DISJOINT_BIT_KHR bit set, the image is described
|
||||
as _disjoint_, and its planes are therefore are bound to memory
|
||||
|
|
@ -864,8 +864,8 @@ Point Sampling (Rasterization)::
|
|||
|
||||
ifdef::VK_KHR_swapchain[]
|
||||
Presentable image::
|
||||
A sname:VkImage object obtained from a sname:sname:VkSwapchainKHR used
|
||||
to present to a sname:VkSurfaceKHR object.
|
||||
A sname:VkImage object obtained from a sname:VkSwapchainKHR used to
|
||||
present to a sname:VkSurfaceKHR object.
|
||||
endif::VK_KHR_swapchain[]
|
||||
|
||||
Preserve Attachment::
|
||||
|
|
|
|||
|
|
@ -48,11 +48,11 @@ include::../../api/protos/vkGetRandROutputDisplayEXT.txt[]
|
|||
* pname:dpy A connection to the X11 server from which pname:rrOutput was
|
||||
queried.
|
||||
* pname:rrOutput An X11 RandR output ID.
|
||||
* pname:pDisplay The corresponding VkDisplayKHR handle will be returned
|
||||
here.
|
||||
* pname:pDisplay The corresponding slink:VkDisplayKHR handle will be
|
||||
returned here.
|
||||
|
||||
If there is no VkDisplayKHR corresponding to pname:rrOutput on
|
||||
pname:physicalDevice, ename:VK_NULL_HANDLE must: be returned in
|
||||
If there is no slink:VkDisplayKHR corresponding to pname:rrOutput on
|
||||
pname:physicalDevice, dlink:VK_NULL_HANDLE must: be returned in
|
||||
pname:pDisplay.
|
||||
|
||||
include::../../validity/protos/vkGetRandROutputDisplayEXT.txt[]
|
||||
|
|
|
|||
|
|
@ -52,8 +52,8 @@ include::../api/structs/VkDebugMarkerObjectNameInfoEXT.txt[]
|
|||
|
||||
Applications may: change the name associated with an object simply by
|
||||
calling fname:vkDebugMarkerSetObjectNameEXT again with a new string.
|
||||
To remove a previously set name, pname:pName should: be set to an empty
|
||||
string.
|
||||
To remove a previously set name, pname:pObjectName should: be set to an
|
||||
empty string.
|
||||
|
||||
.Valid Usage
|
||||
****
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ include::../../api/enums/VkDeviceEventTypeEXT.txt[]
|
|||
--
|
||||
|
||||
To create a fence that will be signaled when an event occurs on a
|
||||
VkDisplayKHR object, call:
|
||||
slink:VkDisplayKHR object, call:
|
||||
|
||||
include::../../api/protos/vkRegisterDisplayEventEXT.txt[]
|
||||
|
||||
|
|
|
|||
|
|
@ -168,12 +168,12 @@ include::../../api/structs/VkPastPresentationTimingGOOGLE.txt[]
|
|||
|
||||
* pname:presentID is an application-provided value that was given to a
|
||||
previous fname:vkQueuePresentKHR command via
|
||||
sname:VkPresentTimeInfoGOOGLE::pname:presentID (see below).
|
||||
slink:VkPresentTimeGOOGLE::pname:presentID (see below).
|
||||
It can: be used to uniquely identify a previous present with the
|
||||
flink:vkQueuePresentKHR command.
|
||||
* pname:desiredPresentTime is an application-provided value that was given
|
||||
to a previous flink:vkQueuePresentKHR command via
|
||||
sname:VkPresentTimeInfoGOOGLE::pname:desiredPresentTime.
|
||||
slink:VkPresentTimeGOOGLE::pname:desiredPresentTime.
|
||||
If non-zero, it was used by the application to indicate that an image
|
||||
not be presented any sooner than pname:desiredPresentTime.
|
||||
* pname:actualPresentTime is the time when the image of the
|
||||
|
|
@ -182,7 +182,7 @@ include::../../api/structs/VkPastPresentationTimingGOOGLE.txt[]
|
|||
pname:swapchain could have been displayed.
|
||||
This may: differ from pname:actualPresentTime if the application
|
||||
requested that the image be presented no sooner than
|
||||
sname:VkPresentTimeInfoGOOGLE::pname:desiredPresentTime.
|
||||
slink:VkPresentTimeGOOGLE::pname:desiredPresentTime.
|
||||
* pname:presentMargin is an indication of how early the
|
||||
fname:vkQueuePresentKHR command was processed compared to how soon it
|
||||
needed to be processed, and still be presented at
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ code:ANativeWindow through other platform mechanisms will fail.
|
|||
In particular, only one sname:VkSurfaceKHR can: exist at a time for a given
|
||||
window.
|
||||
Similarly, a native window cannot: be used by both a sname:VkSurfaceKHR and
|
||||
EGLSurface simultaneously.
|
||||
code:EGLSurface simultaneously.
|
||||
====
|
||||
|
||||
If successful, fname:vkCreateAndroidSurfaceKHR increments the
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ include::../../api/structs/VkDisplayPlanePropertiesKHR.txt[]
|
|||
sname:VK_NULL_HANDLE.
|
||||
* pname:currentStackIndex is the current z-order of the plane.
|
||||
This will be between 0 and the value returned by
|
||||
fname:vkGetPhysicalDeviceDisplayPlanePropertiesKHR() in
|
||||
fname:vkGetPhysicalDeviceDisplayPlanePropertiesKHR in
|
||||
pname:pPropertyCount.
|
||||
|
||||
include::../../validity/structs/VkDisplayPlanePropertiesKHR.txt[]
|
||||
|
|
@ -392,10 +392,10 @@ include::../../api/structs/VkDisplayPlaneCapabilitiesKHR.txt[]
|
|||
this plane using the specified mode.
|
||||
* pname:minDstPosition, pname:maxDstPosition, pname:minDstExtent,
|
||||
pname:maxDstExtent all have similar semantics to their corresponding
|
||||
"Src" equivalents, but apply to the output region within the mode rather
|
||||
than the input region within the source image.
|
||||
Unlike the "Src" offsets, pname:minDstPosition and pname:maxDstPosition
|
||||
may: contain negative values.
|
||||
ptext:Src* equivalents, but apply to the output region within the mode
|
||||
rather than the input region within the source image.
|
||||
Unlike the ptext:Src* offsets, pname:minDstPosition and
|
||||
pname:maxDstPosition may: contain negative values.
|
||||
|
||||
The minimum and maximum position and extent fields describe the hardware
|
||||
limits, if any, as they apply to the specified display mode and plane.
|
||||
|
|
@ -477,8 +477,8 @@ include::../../api/structs/VkDisplaySurfaceCreateInfoKHR.txt[]
|
|||
to use when displaying this surface.
|
||||
* pname:planeIndex is the plane on which this surface appears.
|
||||
* pname:planeStackIndex is the z-order of the plane.
|
||||
* pname:transform is a elink:VkSurfaceTransformFlagBitsKH value specifying
|
||||
the transformation to apply to images as part of the scanout operation.
|
||||
* pname:transform is a elink:VkSurfaceTransformFlagBitsKHR value
|
||||
specifying the transformation to apply to images as part of the scanout operation.
|
||||
* pname:globalAlpha is the global alpha value.
|
||||
This value is ignored if pname:alphaMode is not
|
||||
ename:VK_DISPLAY_PLANE_ALPHA_GLOBAL_BIT_KHR.
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ include::../../validity/structs/VkRectLayerKHR.txt[]
|
|||
|
||||
Some platforms allow the size of a surface to change, and then scale the
|
||||
pixels of the image to fit the surface.
|
||||
VkRectLayerKHR specifies pixels of the swapchain's image(s), which will be
|
||||
constant for the life of the swapchain.
|
||||
sname:VkRectLayerKHR specifies pixels of the swapchain's image(s), which
|
||||
will be constant for the life of the swapchain.
|
||||
|
||||
--
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ include::../../api/protos/vkGetSwapchainStatusKHR.txt[]
|
|||
include::../../validity/protos/vkGetSwapchainStatusKHR.txt[]
|
||||
--
|
||||
|
||||
The possible return values for fname:vkGetSwapchainStatusKHR() should: be
|
||||
The possible return values for fname:vkGetSwapchainStatusKHR should: be
|
||||
interpreted as follows:
|
||||
|
||||
* ename:VK_SUCCESS indicates the presentation engine is presenting the
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Use of these extensions is guarded by preprocessor symbols as defined in the
|
|||
|
||||
In order for an application to be compiled to use WSI with a given platform,
|
||||
it must: #define the appropriate preprocessor symbol prior to including the
|
||||
"vulkan.h" header file.
|
||||
`vulkan.h` header file.
|
||||
Each platform-specific extension is an instance extension.
|
||||
The application must: enable instance extensions with fname:vkCreateInstance
|
||||
before using them.
|
||||
|
|
@ -61,7 +61,7 @@ On certain platforms, the Vulkan loader and ICDs may: have conventions that
|
|||
treat the handle as a pointer to a struct that contains the
|
||||
platform-specific information about the surface.
|
||||
This will be described in the documentation for the loader-ICD interface,
|
||||
and in the "vk_icd.h" header file of the LoaderAndTools source-code
|
||||
and in the `vk_icd.h` header file of the LoaderAndTools source-code
|
||||
repository.
|
||||
This does not affect the loader-layer interface; layers may: wrap
|
||||
sname:VkSurfaceKHR objects.
|
||||
|
|
@ -391,8 +391,8 @@ include::../../api/structs/VkPhysicalDeviceSurfaceInfo2KHR.txt[]
|
|||
* pname:surface is the surface that will be associated with the swapchain.
|
||||
|
||||
The members of sname:VkPhysicalDeviceSurfaceInfo2KHR correspond to the
|
||||
arguments to flink:vkGetPhysicalDeviceSurfaceCapabilities, with pname:sType
|
||||
and pname:pNext added for extensibility.
|
||||
arguments to flink:vkGetPhysicalDeviceSurfaceCapabilitiesKHR, with
|
||||
pname:sType and pname:pNext added for extensibility.
|
||||
|
||||
include::../../validity/structs/VkPhysicalDeviceSurfaceInfo2KHR.txt[]
|
||||
--
|
||||
|
|
|
|||
|
|
@ -436,8 +436,8 @@ endif::VK_KHX_device_group[]
|
|||
The pname:surface must: not be destroyed until after the swapchain is
|
||||
destroyed.
|
||||
|
||||
If pname:oldSwapchain is not VK_NULL_HANDLE then pname:surface must: be
|
||||
associated with pname:oldSwapchain.
|
||||
If pname:oldSwapchain is not dlink:VK_NULL_HANDLE then pname:surface must:
|
||||
be associated with pname:oldSwapchain.
|
||||
Otherwise, the native window referred to by pname:surface must: not already
|
||||
be associated with another swapchain, and must: not be already be associated
|
||||
with a non-Vulkan graphics API surface.
|
||||
|
|
@ -577,7 +577,7 @@ ifdef::VK_KHX_device_group[]
|
|||
|
||||
Images can: also be created by using flink:vkCreateImage with
|
||||
slink:VkImageSwapchainCreateInfoKHX and bound to swapchain memory using
|
||||
flink:vkBindImageMemory2KHX with slink:VkBindImageMemorySwapchainInfoKHX.
|
||||
flink:vkBindImageMemory2KHR with slink:VkBindImageMemorySwapchainInfoKHX.
|
||||
These images can: be used anywhere swapchain images are used, and are useful
|
||||
in logical devices with multiple physical devices to create peer memory
|
||||
bindings of swapchain memory.
|
||||
|
|
@ -797,7 +797,7 @@ the presentable images remain owned by the queue family the image was
|
|||
previously presented on.
|
||||
====
|
||||
|
||||
The possible return values for fname:vkAcquireNextImageKHR() depend on the
|
||||
The possible return values for fname:vkAcquireNextImageKHR depend on the
|
||||
pname:timeout provided:
|
||||
|
||||
* ename:VK_SUCCESS is returned if an image became available.
|
||||
|
|
@ -1180,7 +1180,7 @@ endif::VK_KHR_display_swapchain[]
|
|||
|
||||
The result codes ename:VK_ERROR_OUT_OF_DATE_KHR and ename:VK_SUBOPTIMAL_KHR
|
||||
have the same meaning when returned by fname:vkQueuePresentKHR as they do
|
||||
when returned by fname:vkAcquireNextImageKHR().
|
||||
when returned by fname:vkAcquireNextImageKHR.
|
||||
If multiple swapchains are presented, the result code is determined applying
|
||||
the following rules in order:
|
||||
|
||||
|
|
|
|||
|
|
@ -58,8 +58,8 @@ pname:currentExtent are the window size.
|
|||
Therefore, a swapchain's pname:imageExtent must: match the window's size.
|
||||
|
||||
Some Vulkan functions may: send protocol over the specified xcb connection
|
||||
when using a swapchain or presentable images created from a VkSurface
|
||||
referring to an xcb window.
|
||||
when using a swapchain or presentable images created from a
|
||||
slink:VkSurfaceKHR referring to an xcb window.
|
||||
Applications must: therefore ensure the xcb connection is available to
|
||||
Vulkan for the duration of any functions that manipulate such swapchains or
|
||||
their presentable images, and any functions that build or queue command
|
||||
|
|
|
|||
|
|
@ -23,7 +23,8 @@ by the application will not inherit the handle, as described in the MSDN
|
|||
documentation for "`Synchronization Object Security and Access Rights`"[1].
|
||||
Further, if the structure is not present, the access rights will be
|
||||
|
||||
code:DXGI_SHARED_RESOURCE_READ | code:DXGI_SHARED_RESOURCE_WRITE
|
||||
DXGI_SHARED_RESOURCE_READ | DXGI_SHARED_RESOURCE_WRITE
|
||||
|
||||
|
||||
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686670.aspx
|
||||
|
||||
|
|
|
|||
|
|
@ -560,8 +560,8 @@ include::../validity/protos/vkCmdUpdateBuffer.txt[]
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The pname:pData parameter was of type code:uint32_t*` instead of code:void*
|
||||
The pname:pData parameter was of type code:uint32_t* instead of code:void*
|
||||
prior to revision 1.0.19 of the Specification and dlink:VK_HEADER_VERSION 19
|
||||
of +vulkan.h+.
|
||||
of `vulkan.h`.
|
||||
This was a historical anomaly, as the source data may be of other types.
|
||||
====
|
||||
|
|
|
|||
|
|
@ -73,8 +73,8 @@ Initial::
|
|||
Recording::
|
||||
flink:vkBeginCommandBuffer changes the state of a command buffer from
|
||||
the initial state to the _recording state_.
|
||||
Once a command buffer is in the recording state, vkCmd* commands can: be
|
||||
used to record to the command buffer.
|
||||
Once a command buffer is in the recording state, ftext:vkCmd* commands
|
||||
can: be used to record to the command buffer.
|
||||
Executable::
|
||||
flink:vkEndCommandBuffer ends the recording of a command buffer, and
|
||||
moves it from the recording state to the _executable state_.
|
||||
|
|
|
|||
|
|
@ -468,9 +468,9 @@ include::../api/structs/VkImageCopy.txt[]
|
|||
slink:VkImageSubresourceLayers structures specifying the image
|
||||
subresources of the images used for the source and destination image
|
||||
data, respectively.
|
||||
* pname:srcOffset and pname:dstOffset select the initial x, y, and z
|
||||
offsets in texels of the sub-regions of the source and destination image
|
||||
data.
|
||||
* pname:srcOffset and pname:dstOffset select the initial pname:x, pname:y,
|
||||
and pname:z offsets in texels of the sub-regions of the source and
|
||||
destination image data.
|
||||
* pname:extent is the size in texels of the source image to copy in
|
||||
pname:width, pname:height and pname:depth.
|
||||
|
||||
|
|
@ -971,8 +971,8 @@ include::../api/structs/VkBufferImageCopy.txt[]
|
|||
* pname:imageSubresource is a slink:VkImageSubresourceLayers used to
|
||||
specify the specific image subresources of the image used for the source
|
||||
or destination image data.
|
||||
* pname:imageOffset selects the initial x, y, z offsets in texels of the
|
||||
sub-region of the source or destination image data.
|
||||
* pname:imageOffset selects the initial pname:x, pname:y, pname:z offsets
|
||||
in texels of the sub-region of the source or destination image data.
|
||||
* pname:imageExtent is the size in texels of the image to copy in
|
||||
pname:width, pname:height and pname:depth.
|
||||
|
||||
|
|
@ -1616,8 +1616,9 @@ values for each pixel are resolved in an implementation-dependent manner.
|
|||
If the source formats are integer types, a single sample's value is selected
|
||||
for each pixel.
|
||||
|
||||
pname:srcOffset and pname:dstOffset select the initial x, y, and z offsets
|
||||
in texels of the sub-regions of the source and destination image data.
|
||||
pname:srcOffset and pname:dstOffset select the initial pname:x, pname:y, and
|
||||
pname:z offsets in texels of the sub-regions of the source and destination
|
||||
image data.
|
||||
pname:extent is the size in texels of the source image to resolve in
|
||||
pname:width, pname:height and pname:depth.
|
||||
|
||||
|
|
@ -1732,9 +1733,9 @@ include::../api/structs/VkImageResolve.txt[]
|
|||
subresources of the images used for the source and destination image
|
||||
data, respectively.
|
||||
Resolve of depth/stencil images is not supported.
|
||||
* pname:srcOffset and pname:dstOffset select the initial x, y, and z
|
||||
offsets in texels of the sub-regions of the source and destination image
|
||||
data.
|
||||
* pname:srcOffset and pname:dstOffset select the initial pname:x, pname:y,
|
||||
and pname:z offsets in texels of the sub-regions of the source and
|
||||
destination image data.
|
||||
* pname:extent is the size in texels of the source image to resolve in
|
||||
pname:width, pname:height and pname:depth.
|
||||
|
||||
|
|
|
|||
|
|
@ -620,7 +620,7 @@ include::../api/structs/VkDescriptorSetLayoutCreateInfo.txt[]
|
|||
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
|
||||
* pname:flags is a bitmask
|
||||
ifdef::VK_KHR_push_descriptor[]
|
||||
of elink:VkDescriptorSetLayoutCreateFlags.
|
||||
of elink:VkDescriptorSetLayoutCreateFlagBits
|
||||
endif::VK_KHR_push_descriptor[]
|
||||
specifying options for descriptor set layout creation.
|
||||
* pname:bindingCount is the number of elements in pname:pBindings.
|
||||
|
|
|
|||
|
|
@ -1138,14 +1138,14 @@ queue priority (sname:VkDeviceQueueCreateInfo::pname:pQueuePriorities).
|
|||
Abuse of this feature may result in starving the rest of the system from
|
||||
hardware resources.
|
||||
Therefore, the driver implementation may: deny requests to acquire a
|
||||
priority above the default priority (elink:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM)
|
||||
priority above the default priority (ename:VK_QUEUE_GLOBAL_PRIORITY_MEDIUM)
|
||||
if the caller does not have sufficient privileges.
|
||||
In this scenario elink:VK_ERROR_NOT_PERMITTED_EXT is returned.
|
||||
In this scenario ename:VK_ERROR_NOT_PERMITTED_EXT is returned.
|
||||
|
||||
The driver implementation may: fail the queue allocation request if
|
||||
resources required to complete the operation have been exhausted (either by
|
||||
the same process or a different process).
|
||||
In this scenario elink:VK_ERROR_INITIALIZATION_FAILED is returned.
|
||||
In this scenario ename:VK_ERROR_INITIALIZATION_FAILED is returned.
|
||||
|
||||
endif::VK_EXT_global_priority[]
|
||||
|
||||
|
|
@ -1231,8 +1231,8 @@ different devices.
|
|||
An implementation may: allow a higher-priority queue to starve a
|
||||
lower-priority queue on the same sname:VkDevice until the higher-priority
|
||||
queue has no further commands to execute.
|
||||
The relationship of queue priorities must: not cause queues on one VkDevice
|
||||
to starve queues on another sname:VkDevice.
|
||||
The relationship of queue priorities must: not cause queues on one
|
||||
sname:VkDevice to starve queues on another sname:VkDevice.
|
||||
|
||||
No specific guarantees are made about higher priority queues receiving more
|
||||
processing time or better quality of service than lower priority queues.
|
||||
|
|
|
|||
|
|
@ -881,7 +881,7 @@ If pname:drawCount is less than or equal to one, pname:stride is ignored.
|
|||
* [[VUID-vkCmdDrawIndirect-drawCount-00476]]
|
||||
If pname:drawCount is greater than `1`, pname:stride must: be a multiple
|
||||
of `4` and must: be greater than or equal to
|
||||
sizeof(sname:VkDrawIndirectCommand)
|
||||
code:sizeof(sname:VkDrawIndirectCommand)
|
||||
* [[VUID-vkCmdDrawIndirect-drawCount-00477]]
|
||||
If the <<features-features-multiDrawIndirect,multi-draw indirect>>
|
||||
feature is not enabled, pname:drawCount must: be `0` or `1`
|
||||
|
|
@ -936,13 +936,13 @@ If pname:drawCount is less than or equal to one, pname:stride is ignored.
|
|||
state must: have been set on the current command buffer
|
||||
* [[VUID-vkCmdDrawIndirect-drawCount-00487]]
|
||||
If pname:drawCount is equal to `1`, [eq]#(pname:offset {plus}
|
||||
sizeof(slink:VkDrawIndirectCommand))# must: be less than or equal to the
|
||||
size of pname:buffer
|
||||
code:sizeof(slink:VkDrawIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndirect-drawCount-00488]]
|
||||
If pname:drawCount is greater than `1`, [eq]#(pname:stride {times}
|
||||
(pname:drawCount - 1) {plus} pname:offset {plus}
|
||||
sizeof(slink:VkDrawIndirectCommand))# must: be less than or equal to the
|
||||
size of pname:buffer
|
||||
code:sizeof(slink:VkDrawIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndirect-drawCount-00489]]
|
||||
pname:drawCount must: be less than or equal to
|
||||
sname:VkPhysicalDeviceLimits::pname:maxDrawIndirectCount
|
||||
|
|
@ -1112,12 +1112,12 @@ located at pname:countBufferOffset and use this as the draw count.
|
|||
pname:countBufferOffset must: be a multiple of `4`
|
||||
* [[VUID-vkCmdDrawIndirectCountAMD-stride-00504]]
|
||||
pname:stride must: be a multiple of `4` and must: be greater than or
|
||||
equal to sizeof(sname:VkDrawIndirectCommand)
|
||||
equal to code:sizeof(sname:VkDrawIndirectCommand)
|
||||
* [[VUID-vkCmdDrawIndirectCountAMD-maxDrawCount-00505]]
|
||||
If pname:maxDrawCount is greater than or equal to `1`,
|
||||
[eq]#(pname:stride {times} (pname:maxDrawCount - 1) {plus} pname:offset
|
||||
{plus} sizeof(sname:VkDrawIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
{plus} code:sizeof(sname:VkDrawIndirectCommand))# must: be less than or
|
||||
equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndirectCountAMD-firstInstance-00506]]
|
||||
If the
|
||||
<<features-features-drawIndirectFirstInstance,drawIndirectFirstInstance>>
|
||||
|
|
@ -1169,13 +1169,13 @@ located at pname:countBufferOffset and use this as the draw count.
|
|||
state must: have been set on the current command buffer
|
||||
* [[VUID-vkCmdDrawIndirectCountAMD-countBuffer-00515]]
|
||||
If the count stored in pname:countBuffer is equal to `1`,
|
||||
[eq]#(pname:offset {plus} sizeof(sname:VkDrawIndirectCommand))# must: be
|
||||
less than or equal to the size of pname:buffer
|
||||
[eq]#(pname:offset {plus} code:sizeof(sname:VkDrawIndirectCommand))#
|
||||
must: be less than or equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndirectCountAMD-countBuffer-00516]]
|
||||
If the count stored in pname:countBuffer is greater than `1`,
|
||||
[eq]#(pname:stride {times} (pname:drawCount - 1) {plus} pname:offset
|
||||
{plus} sizeof(sname:VkDrawIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
{plus} code:sizeof(sname:VkDrawIndirectCommand))# must: be less than or
|
||||
equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndirectCountAMD-countBuffer-00517]]
|
||||
The count stored in pname:countBuffer must: be less than or equal to
|
||||
sname:VkPhysicalDeviceLimits::pname:maxDrawIndirectCount
|
||||
|
|
@ -1289,7 +1289,7 @@ If pname:drawCount is less than or equal to one, pname:stride is ignored.
|
|||
* [[VUID-vkCmdDrawIndexedIndirect-drawCount-00528]]
|
||||
If pname:drawCount is greater than `1`, pname:stride must: be a multiple
|
||||
of `4` and must: be greater than or equal to
|
||||
sizeof(sname:VkDrawIndexedIndirectCommand)
|
||||
code:sizeof(sname:VkDrawIndexedIndirectCommand)
|
||||
* [[VUID-vkCmdDrawIndexedIndirect-drawCount-00529]]
|
||||
If the <<features-features-multiDrawIndirect,multi-draw indirect>>
|
||||
feature is not enabled, pname:drawCount must: be `0` or `1`
|
||||
|
|
@ -1344,13 +1344,13 @@ If pname:drawCount is less than or equal to one, pname:stride is ignored.
|
|||
state must: have been set on the current command buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirect-drawCount-00539]]
|
||||
If pname:drawCount is equal to `1`, [eq]#(pname:offset {plus}
|
||||
sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
code:sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less than or
|
||||
equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirect-drawCount-00540]]
|
||||
If pname:drawCount is greater than `1`, [eq]#(pname:stride {times}
|
||||
(pname:drawCount - 1) {plus} pname:offset {plus}
|
||||
sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
code:sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less than or
|
||||
equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirect-drawCount-00541]]
|
||||
pname:drawCount must: be less than or equal to
|
||||
sname:VkPhysicalDeviceLimits::pname:maxDrawIndirectCount
|
||||
|
|
@ -1529,18 +1529,18 @@ located at pname:countBufferOffset and use this as the draw count.
|
|||
pname:countBufferOffset must: be a multiple of `4`
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-stride-00557]]
|
||||
pname:stride must: be a multiple of `4` and must: be greater than or
|
||||
equal to sizeof(sname:VkDrawIndirectCommand)
|
||||
equal to code:sizeof(sname:VkDrawIndirectCommand)
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-maxDrawCount-00558]]
|
||||
If pname:maxDrawCount is greater than or equal to `1`,
|
||||
[eq]#(pname:stride {times} (pname:maxDrawCount - 1) {plus} pname:offset
|
||||
{plus} sizeof(sname:VkDrawIndirectCommand))# must: be less than or equal
|
||||
to the size of pname:buffer
|
||||
{plus} code:sizeof(sname:VkDrawIndirectCommand))# must: be less than or
|
||||
equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-firstInstance-00559]]
|
||||
If the
|
||||
<<features-features-drawIndirectFirstInstance,drawIndirectFirstInstance>>
|
||||
feature is not enabled, all the pname:firstInstance members of the
|
||||
sname:VkDrawIndexedIndirectCommand structures accessed by this command
|
||||
must: be code:0
|
||||
must: be `0`
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-renderPass-00560]]
|
||||
The current render pass must: be <<renderpass-compatibility,compatible>>
|
||||
with the pname:renderPass member of the
|
||||
|
|
@ -1586,13 +1586,13 @@ located at pname:countBufferOffset and use this as the draw count.
|
|||
state must: have been set on the current command buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-countBuffer-00568]]
|
||||
If count stored in pname:countBuffer is equal to `1`, [eq]#(pname:offset
|
||||
{plus} sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less than
|
||||
or equal to the size of pname:buffer
|
||||
{plus} code:sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less
|
||||
than or equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-countBuffer-00569]]
|
||||
If count stored in pname:countBuffer is greater than `1`,
|
||||
[eq]#(pname:stride {times} (pname:drawCount - 1) {plus} pname:offset
|
||||
{plus} sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less than
|
||||
or equal to the size of pname:buffer
|
||||
{plus} code:sizeof(sname:VkDrawIndexedIndirectCommand))# must: be less
|
||||
than or equal to the size of pname:buffer
|
||||
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-drawCount-00570]]
|
||||
pname:drawCount must: be less than or equal to
|
||||
sname:VkPhysicalDeviceLimits::pname:maxDrawIndirectCount
|
||||
|
|
|
|||
|
|
@ -232,7 +232,7 @@ include::../api/protos/vkEnumerateInstanceExtensionProperties.txt[]
|
|||
* pname:pProperties is either `NULL` or a pointer to an array of
|
||||
slink:VkExtensionProperties structures.
|
||||
|
||||
When pname:pLayerName parameter is NULL, only extensions provided by the
|
||||
When pname:pLayerName parameter is `NULL`, only extensions provided by the
|
||||
Vulkan implementation or by implicitly enabled layers are returned.
|
||||
When pname:pLayerName is the name of a layer, the instance extensions
|
||||
provided by that layer are returned.
|
||||
|
|
@ -286,7 +286,7 @@ include::../api/protos/vkEnumerateDeviceExtensionProperties.txt[]
|
|||
* pname:pProperties is either `NULL` or a pointer to an array of
|
||||
slink:VkExtensionProperties structures.
|
||||
|
||||
When pname:pLayerName parameter is NULL, only extensions provided by the
|
||||
When pname:pLayerName parameter is `NULL`, only extensions provided by the
|
||||
Vulkan implementation or by implicitly enabled layers are returned.
|
||||
When pname:pLayerName is the name of a layer, the device extensions provided
|
||||
by that layer are returned.
|
||||
|
|
|
|||
|
|
@ -894,9 +894,9 @@ structure describe the following features:
|
|||
to execute atomically and in <<drawing-primitive-order, primitive
|
||||
order>>.
|
||||
If this is ename:VK_TRUE,
|
||||
elink:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is treated the
|
||||
same as VK_ACCESS_COLOR_ATTACHMENT_READ_BIT and advanced blending needs
|
||||
no additional synchronization over basic blending.
|
||||
ename:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is treated the
|
||||
same as ename:VK_ACCESS_COLOR_ATTACHMENT_READ_BIT and advanced blending
|
||||
needs no additional synchronization over basic blending.
|
||||
If this is ename:VK_FALSE, then memory dependencies are required to
|
||||
guarantee order between two advanced blending operations that occur on
|
||||
the same sample.
|
||||
|
|
@ -1615,7 +1615,7 @@ ifdef::VK_EXT_discard_rectangles[]
|
|||
endif::VK_EXT_discard_rectangles[]
|
||||
ifdef::VK_KHR_maintenance2[]
|
||||
* [[features-limits-pointClipping]]
|
||||
sname:VkPhysicalDevicePointClippingPropertiesKHR::pname:pointClippingBehavior
|
||||
slink:VkPhysicalDevicePointClippingPropertiesKHR::pname:pointClippingBehavior
|
||||
defines the clipping behavior of points.
|
||||
This limit can be queried by setting the pname:pNext pointer from a
|
||||
slink:VkPhysicalDeviceProperties2KHR object to an instance of
|
||||
|
|
@ -3060,7 +3060,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
|
||||
= j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3075,7 +3075,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
|
||||
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width and height that is a
|
||||
|
|
@ -3087,7 +3087,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3101,7 +3101,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width that is a multiple
|
||||
|
|
@ -3112,7 +3112,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
Each plane has the same dimensions and each R, G and B component
|
||||
contributes to a single texel.
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3177,7 +3177,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
|
||||
= j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3195,7 +3195,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
|
||||
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width and height that is a
|
||||
|
|
@ -3210,7 +3210,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3227,7 +3227,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width that is a multiple
|
||||
|
|
@ -3241,7 +3241,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
Each plane has the same dimensions and each R, G and B component
|
||||
contributes to a single texel.
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3306,7 +3306,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
|
||||
= j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3324,7 +3324,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
|
||||
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width and height that is a
|
||||
|
|
@ -3339,7 +3339,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3356,7 +3356,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width that is a multiple
|
||||
|
|
@ -3370,7 +3370,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
Each plane has the same dimensions and each R, G and B component
|
||||
contributes to a single texel.
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3414,7 +3414,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
|
||||
= j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3430,7 +3430,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
|
||||
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width and height that is a
|
||||
|
|
@ -3443,7 +3443,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3458,7 +3458,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
image dimensions, and each R and B value is shared with the G components
|
||||
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the BR plane.
|
||||
Images in this format must: be defined with a width that is a multiple
|
||||
|
|
@ -3470,7 +3470,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
|
|||
Each plane has the same dimensions and each R, G and B component
|
||||
contributes to a single texel.
|
||||
The location of each plane when this image is in linear layout can be
|
||||
determined via vkGetImageSubresourceLayout, using
|
||||
determined via flink:vkGetImageSubresourceLayout, using
|
||||
ename:VK_IMAGE_ASPECT_PLANE_0_BIT_KHR for the G plane,
|
||||
ename:VK_IMAGE_ASPECT_PLANE_1_BIT_KHR for the B plane, and
|
||||
ename:VK_IMAGE_ASPECT_PLANE_2_BIT_KHR for the R plane.
|
||||
|
|
@ -3619,7 +3619,7 @@ element, rather than individual components occupying a single data element:
|
|||
A "`format`" is represented by a single enum value.
|
||||
The name of a format is usually built up by using the following pattern:
|
||||
|
||||
etext:VK_FORMAT_{component-format|compression-scheme}_{numeric-format}
|
||||
VK_FORMAT_{component-format|compression-scheme}_{numeric-format}
|
||||
|
||||
The component-format specifies either the size of the R, G, B, and A
|
||||
components (if they are present) in the case of a color format, or the size
|
||||
|
|
@ -4738,7 +4738,7 @@ s| Format ^.^| {downarrow}
|
|||
|====
|
||||
|
||||
[[features-formats-mandatory-features-depth-stencil]]
|
||||
.Mandatory format support: depth/stencil with elink:VkImageType ename:VK_IMAGE_TYPE_2D
|
||||
.Mandatory format support: depth/stencil with ename:VkImageType ename:VK_IMAGE_TYPE_2D
|
||||
[width="100%",cols="10,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|
||||
|====
|
||||
14+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT
|
||||
|
|
@ -4771,7 +4771,7 @@ ename:VK_FORMAT_D24_UNORM_S8_UINT and ename:VK_FORMAT_D32_SFLOAT_S8_UINT.
|
|||
<<<
|
||||
|
||||
[[features-formats-mandatory-features-bcn]]
|
||||
.Mandatory format support: BC compressed formats with elink:VkImageType ename:VK_IMAGE_TYPE_2D and ename:VK_IMAGE_TYPE_3D
|
||||
.Mandatory format support: BC compressed formats with ename:VkImageType ename:VK_IMAGE_TYPE_2D and ename:VK_IMAGE_TYPE_3D
|
||||
[width="100%",cols="10,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|
||||
|====
|
||||
14+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT
|
||||
|
|
@ -4815,7 +4815,7 @@ one of: this table, <<features-formats-mandatory-features-etc>>, or
|
|||
<<<
|
||||
|
||||
[[features-formats-mandatory-features-etc]]
|
||||
.Mandatory format support: ETC2 and EAC compressed formats with elink:VkImageType ename:VK_IMAGE_TYPE_2D
|
||||
.Mandatory format support: ETC2 and EAC compressed formats with ename:VkImageType ename:VK_IMAGE_TYPE_2D
|
||||
[width="100%",cols="10,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|
||||
|====
|
||||
14+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT
|
||||
|
|
@ -4853,7 +4853,7 @@ one of: this table, <<features-formats-mandatory-features-bcn>>, or
|
|||
<<<
|
||||
|
||||
[[features-formats-mandatory-features-astc]]
|
||||
.Mandatory format support: ASTC LDR compressed formats with elink:VkImageType ename:VK_IMAGE_TYPE_2D
|
||||
.Mandatory format support: ASTC LDR compressed formats with ename:VkImageType ename:VK_IMAGE_TYPE_2D
|
||||
[width="100%",cols="10,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|
||||
|====
|
||||
14+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT
|
||||
|
|
@ -5125,7 +5125,7 @@ include::../api/structs/VkPhysicalDeviceImageFormatInfo2KHR.txt[]
|
|||
fname:vkGetPhysicalDeviceImageFormatProperties2KHR.
|
||||
* pname:format is a elink:VkFormat value indicating the image format,
|
||||
corresponding to slink:VkImageCreateInfo::pname:format.
|
||||
* pname:type is a elink:VkImateType value indicating the image type,
|
||||
* pname:type is a elink:VkImageType value indicating the image type,
|
||||
corresponding to slink:VkImageCreateInfo::pname:imageType.
|
||||
* pname:tiling is a elink:VkImageTiling value indicating the image tiling,
|
||||
corresponding to slink:VkImageCreateInfo::pname:tiling.
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ pname:discardRectangleCount)#.
|
|||
ename:VK_DYNAMIC_STATE_DISCARD_RECTANGLE_EXT dynamic state enabled
|
||||
* [[VUID-vkCmdSetDiscardRectangleEXT-firstDiscardRectangle-00584]]
|
||||
pname:firstDiscardRectangle must: be less than
|
||||
sname:VkPhysicalDeviceDiscardRectanglePropertiesEXT.pname:maxDiscardRectangles
|
||||
slink:VkPhysicalDeviceDiscardRectanglePropertiesEXT::pname:maxDiscardRectangles
|
||||
* [[VUID-vkCmdSetDiscardRectangleEXT-firstDiscardRectangle-00585]]
|
||||
The sum of pname:firstDiscardRectangle and pname:discardRectangleCount
|
||||
must: be between `1` and
|
||||
|
|
|
|||
|
|
@ -458,7 +458,7 @@ code:instanceIndex is calculated as follows:
|
|||
* Let code:bindingDesc be the member of
|
||||
sname:VkPipelineVertexInputStateCreateInfo::pname:pVertexBindingDescriptions
|
||||
with sname:VkVertexInputAttributeDescription::pname:binding equal to
|
||||
attribDesc.binding.
|
||||
code:attribDesc.binding.
|
||||
* Let code:vertexIndex be the index of the vertex within the draw (a value
|
||||
between pname:firstVertex and pname:firstVertex+pname:vertexCount for
|
||||
fname:vkCmdDraw, or a value taken from the index buffer for
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ For example, pname:pfnAllocation (or pname:pfnReallocation) could cause
|
|||
termination of running Vulkan instance(s) on a failed allocation for
|
||||
debugging purposes, either directly or indirectly.
|
||||
In these circumstances, it cannot: be assumed that any part of any affected
|
||||
VkInstance objects are going to operate correctly (even
|
||||
slink:VkInstance objects are going to operate correctly (even
|
||||
flink:vkDestroyInstance), and the application must: ensure it cleans up
|
||||
properly via other means (e.g. process termination).
|
||||
====
|
||||
|
|
@ -790,7 +790,7 @@ When memory is allocated, its contents are undefined.
|
|||
There is an implementation-dependent maximum number of memory allocations
|
||||
that can: be simultaneously created on a device.
|
||||
This is specified by the
|
||||
<<features-limits-maxMemoryAllocationCount,pname:maxMemoryAllocationCount>>
|
||||
<<features-limits-maxMemoryAllocationCount,maxMemoryAllocationCount>>
|
||||
member of the slink:VkPhysicalDeviceLimits structure.
|
||||
If pname:maxMemoryAllocationCount is exceeded, fname:vkAllocateMemory will
|
||||
return ename:VK_ERROR_TOO_MANY_OBJECTS.
|
||||
|
|
|
|||
|
|
@ -580,7 +580,7 @@ endif::VK_NV_glsl_shader[]
|
|||
chapter
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-00743]]
|
||||
If rasterization is not disabled and pname:subpass uses a depth/stencil
|
||||
attachment in pname:renderpass that has a layout of
|
||||
attachment in pname:renderPass that has a layout of
|
||||
ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL
|
||||
ifdef::VK_KHR_maintenance2[]
|
||||
or ename:VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR
|
||||
|
|
@ -590,7 +590,7 @@ endif::VK_KHR_maintenance2[]
|
|||
ename:VK_FALSE
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-00744]]
|
||||
If rasterization is not disabled and pname:subpass uses a depth/stencil
|
||||
attachment in pname:renderpass that has a layout of
|
||||
attachment in pname:renderPass that has a layout of
|
||||
ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL
|
||||
ifdef::VK_KHR_maintenance2[]
|
||||
or ename:VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR
|
||||
|
|
@ -733,7 +733,7 @@ endif::VK_NV_framebuffer_mixed_samples[]
|
|||
pname:pMultisampleState must: follow the rules for a
|
||||
<<renderpass-noattachments, zero-attachment subpass>>
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-00759]]
|
||||
pname:subpass must: be a valid subpass within pname:renderpass
|
||||
pname:subpass must: be a valid subpass within pname:renderPass
|
||||
ifdef::VK_KHX_multiview[]
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-renderPass-00760]]
|
||||
If the pname:renderPass has multiview enabled and pname:subpass has more
|
||||
|
|
@ -762,7 +762,7 @@ ifdef::VK_KHR_maintenance2[]
|
|||
* [[VUID-VkGraphicsPipelineCreateInfo-pStages-01565]]
|
||||
If pname:pStages includes a fragment shader stage and an input
|
||||
attachment was referenced by the
|
||||
slink:VkRenderPassInputAttachmentAspectCreateInfoKHR at renderpass
|
||||
slink:VkRenderPassInputAttachmentAspectCreateInfoKHR at pname:renderPass
|
||||
create time, its shader code must: not read from any aspect that was not
|
||||
specified in the pname:aspectMask of the corresponding
|
||||
slink:VkInputAttachmentAspectReferenceKHR structure.
|
||||
|
|
|
|||
|
|
@ -1183,7 +1183,7 @@ floating-point representation.
|
|||
ename:VK_DYNAMIC_STATE_DEPTH_BIAS dynamic state enabled
|
||||
* [[VUID-vkCmdSetDepthBias-depthBiasClamp-00790]]
|
||||
If the <<features-features-depthBiasClamp,depth bias clamping>> feature
|
||||
is not enabled, pname:depthBiasClamp must: be code:0.0
|
||||
is not enabled, pname:depthBiasClamp must: be `0.0`
|
||||
****
|
||||
|
||||
include::../validity/protos/vkCmdSetDepthBias.txt[]
|
||||
|
|
|
|||
|
|
@ -1689,7 +1689,7 @@ endif::VK_KHR_maintenance2[]
|
|||
* [[VUID-vkCmdBeginRenderPass-srcStageMask-00901]]
|
||||
The pname:srcStageMask and pname:dstStageMask members of any element of
|
||||
the pname:pDependencies member of slink:VkRenderPassCreateInfo used to
|
||||
create pname:renderpass must: be supported by the capabilities of the
|
||||
create pname:renderPass must: be supported by the capabilities of the
|
||||
queue family identified by the pname:queueFamilyIndex member of the
|
||||
slink:VkCommandPoolCreateInfo used to create the command pool which
|
||||
pname:commandBuffer was allocated from.
|
||||
|
|
@ -1884,7 +1884,7 @@ ignored.
|
|||
* [[VUID-VkSubpassSampleLocationsEXT-subpassIndex-01532]]
|
||||
pname:subpassIndex must: be less than the pname:subpassCount specified
|
||||
in slink:VkRenderPassCreateInfo the render pass specified by
|
||||
slink:VkRenderPassBeginInfo::pname::renderPass was created with
|
||||
slink:VkRenderPassBeginInfo::pname:renderPass was created with
|
||||
****
|
||||
|
||||
include::../validity/structs/VkSubpassSampleLocationsEXT.txt[]
|
||||
|
|
|
|||
|
|
@ -138,9 +138,9 @@ ifdef::VK_KHR_external_memory[]
|
|||
If the pname:pNext chain contains an instance of
|
||||
slink:VkExternalMemoryBufferCreateInfoKHR, its pname:handleTypes member
|
||||
must: only contain bits that are also in
|
||||
slink:VkExternalBufferPropertiesKHR::pname:externalMemoryProperties.pname:compatibleHandleTypes,
|
||||
slink:VkExternalBufferPropertiesKHR::pname:externalMemoryProperties.compatibleHandleTypes,
|
||||
as returned by flink:vkGetPhysicalDeviceExternalBufferPropertiesKHR with
|
||||
pname:pExternalBufferInfo->pname:handleType equal to any one of the
|
||||
pname:pExternalBufferInfo\->pname:handleType equal to any one of the
|
||||
handle types specified in
|
||||
slink:VkExternalMemoryBufferCreateInfoKHR::pname:handleTypes
|
||||
endif::VK_KHR_external_memory[]
|
||||
|
|
@ -658,19 +658,19 @@ endif::VK_KHR_maintenance1[]
|
|||
contain ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, pname:extent.width
|
||||
and pname:extent.height must: be less than or equal to
|
||||
sname:VkPhysicalDeviceLimits::pname:maxImageDimension2D, or
|
||||
sname:VkImageFormatProperties::pname:maxExtent.width/height (as returned
|
||||
by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format,
|
||||
pname:imageType, pname:tiling, pname:usage, and pname:flags equal to
|
||||
those in this structure) - whichever is higher
|
||||
sname:VkImageFormatProperties::pname:maxExtent.width/pname:height (as
|
||||
returned by fname:vkGetPhysicalDeviceImageFormatProperties with
|
||||
pname:format, pname:imageType, pname:tiling, pname:usage, and
|
||||
pname:flags equal to those in this structure) - whichever is higher
|
||||
* [[VUID-VkImageCreateInfo-imageType-00953]]
|
||||
If pname:imageType is ename:VK_IMAGE_TYPE_2D and pname:flags contains
|
||||
ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, pname:extent.width and
|
||||
pname:extent.height must: be less than or equal to
|
||||
sname:VkPhysicalDeviceLimits::pname:maxImageDimensionCube, or
|
||||
sname:VkImageFormatProperties::pname:maxExtent.width/height (as returned
|
||||
by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format,
|
||||
pname:imageType, pname:tiling, pname:usage, and pname:flags equal to
|
||||
those in this structure) - whichever is higher
|
||||
sname:VkImageFormatProperties::pname:maxExtent.width/pname:height (as
|
||||
returned by fname:vkGetPhysicalDeviceImageFormatProperties with
|
||||
pname:format, pname:imageType, pname:tiling, pname:usage, and
|
||||
pname:flags equal to those in this structure) - whichever is higher
|
||||
* [[VUID-VkImageCreateInfo-imageType-00954]]
|
||||
If pname:imageType is ename:VK_IMAGE_TYPE_2D and pname:flags contains
|
||||
ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, pname:extent.width and
|
||||
|
|
@ -680,8 +680,8 @@ endif::VK_KHR_maintenance1[]
|
|||
If pname:imageType is ename:VK_IMAGE_TYPE_3D, pname:extent.width,
|
||||
pname:extent.height and pname:extent.depth must: be less than or equal
|
||||
to sname:VkPhysicalDeviceLimits::pname:maxImageDimension3D, or
|
||||
sname:VkImageFormatProperties::pname:maxExtent.width/height/depth (as
|
||||
returned by fname:vkGetPhysicalDeviceImageFormatProperties with
|
||||
sname:VkImageFormatProperties::pname:maxExtent.width/pname:height/pname:depth
|
||||
(as returned by fname:vkGetPhysicalDeviceImageFormatProperties with
|
||||
pname:format, pname:imageType, pname:tiling, pname:usage, and
|
||||
pname:flags equal to those in this structure) - whichever is higher
|
||||
* [[VUID-VkImageCreateInfo-imageType-00956]]
|
||||
|
|
@ -3086,12 +3086,12 @@ ifdef::VK_KHR_dedicated_allocation[]
|
|||
pname:buffer
|
||||
* [[VUID-vkBindBufferMemory-memory-01508]]
|
||||
If the sname:VkmemoryAllocateInfo provided when pname:memory was
|
||||
allocated included an instance of slink:VkMemoryDedicatedAllocateInfo in
|
||||
its pname:pNext chain, and
|
||||
slink:VkMemoryDedicatedAllocateInfo::pname:buffer was not
|
||||
allocated included an instance of slink:VkMemoryDedicatedAllocateInfoKHR
|
||||
in its pname:pNext chain, and
|
||||
slink:VkMemoryDedicatedAllocateInfoKHR::pname:buffer was not
|
||||
ename:VK_NULL_HANDLE, then pname:buffer must: equal
|
||||
slink:VkMemoryDedicatedAllocateInfo::pname:buffer and pname:memoryOffset
|
||||
must: be zero.
|
||||
slink:VkMemoryDedicatedAllocateInfoKHR::pname:buffer and
|
||||
pname:memoryOffset must: be zero.
|
||||
endif::VK_KHR_dedicated_allocation[]
|
||||
ifdef::VK_NV_dedicated_allocation[]
|
||||
* [[VUID-vkBindBufferMemory-buffer-01038]]
|
||||
|
|
@ -3351,12 +3351,12 @@ ifdef::VK_KHR_dedicated_allocation[]
|
|||
slink:VkMemoryDedicatedAllocateInfoKHR::pname:image equal to pname:image
|
||||
* [[VUID-vkBindImageMemory-memory-01509]]
|
||||
If the sname:VkmemoryAllocateInfo provided when pname:memory was
|
||||
allocated included an instance of slink:VkMemoryDedicatedAllocateInfo in
|
||||
its pname:pNext chain, and
|
||||
slink:VkMemoryDedicatedAllocateInfo::pname:image was not
|
||||
allocated included an instance of slink:VkMemoryDedicatedAllocateInfoKHR
|
||||
in its pname:pNext chain, and
|
||||
slink:VkMemoryDedicatedAllocateInfoKHR::pname:image was not
|
||||
ename:VK_NULL_HANDLE, then pname:image must: equal
|
||||
slink:VkMemoryDedicatedAllocateInfo::pname:image and pname:memoryOffset
|
||||
must: be zero.
|
||||
slink:VkMemoryDedicatedAllocateInfoKHR::pname:image and
|
||||
pname:memoryOffset must: be zero.
|
||||
endif::VK_KHR_dedicated_allocation[]
|
||||
ifdef::VK_NV_dedicated_allocation[]
|
||||
* [[VUID-vkBindImageMemory-image-01050]]
|
||||
|
|
@ -3548,7 +3548,7 @@ ifdef::VK_KHX_device_group[]
|
|||
If the pname:pNext chain includes
|
||||
slink:VkBindImageMemoryDeviceGroupInfoKHX, the union of the areas of all
|
||||
elements of slink:VkBindImageMemoryDeviceGroupInfoKHX::pname:pSFRRects
|
||||
that correspond to the same instance of pname: image must: cover the
|
||||
that correspond to the same instance of pname:image must: cover the
|
||||
entire image.
|
||||
* [[VUID-VkBindImageMemoryInfoKHR-image-01630]]
|
||||
If pname:image was created with a valid swapchain handle in
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ pname:maxLod of zero also works.
|
|||
|
||||
The maximum number of sampler objects which can: be simultaneously created
|
||||
on a device is implementation-dependent and specified by the
|
||||
<<features-limits-maxSamplerAllocationCount,pname:maxSamplerAllocationCount>>
|
||||
<<features-limits-maxSamplerAllocationCount,maxSamplerAllocationCount>>
|
||||
member of the slink:VkPhysicalDeviceLimits structure.
|
||||
If pname:maxSamplerAllocationCount is exceeded, fname:vkCreateSampler will
|
||||
return ename:VK_ERROR_TOO_MANY_OBJECTS.
|
||||
|
|
@ -431,7 +431,7 @@ The sname:VkSamplerYcbcrConversionInfoKHR structure is defined as:
|
|||
include::../api/structs/VkSamplerYcbcrConversionInfoKHR.txt[]
|
||||
|
||||
* pname:sType is the type of this structure.
|
||||
* pname:pNext is 'NULL' or a pointer to an extension-specific structure.
|
||||
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
|
||||
* pname:conversion is a slink:VkSamplerYcbcrConversionKHR handle created
|
||||
with flink:vkCreateSamplerYcbcrConversionKHR.
|
||||
|
||||
|
|
@ -544,7 +544,7 @@ the default mode of operation.
|
|||
pname:format must: represent unsigned normalized values (i.e. the format
|
||||
must be a etext:UNORM format)
|
||||
* [[VUID-VkSamplerYcbcrConversionCreateInfoKHR-None-01654]]
|
||||
If the format has a _422 or _420 suffix:
|
||||
If the format has a etext:_422 or etext:_420 suffix:
|
||||
** pname:components.g must: be ename:VK_COMPONENT_SWIZZLE_IDENTITY
|
||||
** pname:components.a must: be ename:VK_COMPONENT_SWIZZLE_IDENTITY,
|
||||
ename:VK_COMPONENT_SWIZZLE_ONE, or ename:VK_COMPONENT_SWIZZLE_ZERO
|
||||
|
|
|
|||
|
|
@ -1955,7 +1955,7 @@ ifdef::VK_KHR_external_semaphore_win32[]
|
|||
--
|
||||
|
||||
To specify additional attributes of NT handles exported from a semaphore,
|
||||
add the slink:VkExportSemaphoreWin32HandleInfoKHR structure to the
|
||||
add the sname:VkExportSemaphoreWin32HandleInfoKHR structure to the
|
||||
pname:pNext chain of the slink:VkSemaphoreCreateInfo structure.
|
||||
The sname:VkExportSemaphoreWin32HandleInfoKHR structure is defined as:
|
||||
|
||||
|
|
@ -1999,8 +1999,8 @@ ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT_KHR
|
|||
If slink:VkExportSemaphoreCreateInfoKHR::pname:handleTypes does not
|
||||
include ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR or
|
||||
ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT_KHR,
|
||||
VkExportSemaphoreWin32HandleInfoKHR must: not be in the pname:pNext
|
||||
chain of slink:VkSemaphoreCreateInfo.
|
||||
sname:VkExportSemaphoreWin32HandleInfoKHR must: not be in the
|
||||
pname:pNext chain of slink:VkSemaphoreCreateInfo.
|
||||
****
|
||||
|
||||
include::../validity/structs/VkExportSemaphoreWin32HandleInfoKHR.txt[]
|
||||
|
|
|
|||
|
|
@ -429,7 +429,7 @@ conversion>>.
|
|||
|
||||
code:OpImageFetch, code:OpImageSparseFetch, code:OpImage*code:Gather, and
|
||||
code:OpImageSparse*code:Gather must: not be used with a sampler that enables
|
||||
<<samplers-YCbCr-conversion,sampler Y'C~B~C~R~ conversion>>.
|
||||
<<samplers-YCbCr-conversion,sampler Y\'C~B~C~R~ conversion>>.
|
||||
|
||||
The code:ConstOffset and code:Offset operands must: not be used with a
|
||||
sampler that enables <<samplers-YCbCr-conversion,sampler Y'C~B~C~R~
|
||||
|
|
@ -2142,9 +2142,9 @@ texture value.
|
|||
When set to ename:VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT, a weighted
|
||||
average is computed.
|
||||
If the reduction mode is ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
|
||||
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT, reduce() computes a component-wise
|
||||
minimum or maximum, respectively, of the components of the set of provided
|
||||
texels with non-zero weights.
|
||||
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT, [eq]#reduce()# computes a
|
||||
component-wise minimum or maximum, respectively, of the components of the
|
||||
set of provided texels with non-zero weights.
|
||||
endif::VK_EXT_sampler_filter_minmax[]
|
||||
|
||||
ifdef::VK_IMG_filter_cubic[]
|
||||
|
|
|
|||
|
|
@ -431,7 +431,7 @@ table:
|
|||
necessary>>.
|
||||
| elink{cl} | Formats the macro argument as a Vulkan enumerated
|
||||
type name and links to the definition of that enumeration
|
||||
type. Example: ename{cl}VkResult -> ename:VkResult.
|
||||
type. Example: elink{cl}VkResult -> elink:VkResult.
|
||||
| ename{cl} | Formats the macro argument as a Vulkan enumerant name.
|
||||
Example: ename{cl}VK_EVENT_SET -> ename:VK_EVENT_SET.
|
||||
| etext{cl} | Formats the macro argument like ename{cl}. Not validated.
|
||||
|
|
|
|||
Loading…
Reference in New Issue