From d0eb98eb896ed17a0ec939a3c1168143481ae2b0 Mon Sep 17 00:00:00 2001 From: Petr Kraus Date: Thu, 9 Nov 2017 00:09:27 +0100 Subject: [PATCH] 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... --- ChangeLog.txt | 2 +- .../VK_AMD_shader_fragment_mask.txt | 6 +- .../vulkan/appendices/VK_EXT_debug_marker.txt | 2 +- .../vulkan/appendices/VK_EXT_debug_report.txt | 12 ++-- .../appendices/VK_EXT_global_priority.txt | 12 ++-- .../vulkan/appendices/VK_EXT_hdr_metadata.txt | 4 +- .../appendices/VK_EXT_sample_locations.txt | 2 +- .../VK_EXT_shader_subgroup_ballot.txt | 20 +++---- .../VK_EXT_shader_subgroup_vote.txt | 4 +- .../appendices/VK_KHR_android_surface.txt | 2 +- .../vulkan/appendices/VK_KHR_display.txt | 11 ++-- .../appendices/VK_KHR_display_swapchain.txt | 14 ++--- .../appendices/VK_KHR_external_memory.txt | 23 +++---- .../VK_KHR_external_memory_win32.txt | 4 +- .../VK_KHR_external_semaphore_win32.txt | 2 +- .../VK_KHR_get_memory_requirements2.txt | 7 ++- .../appendices/VK_KHR_incremental_present.txt | 5 +- .../vulkan/appendices/VK_KHR_maintenance1.txt | 6 +- .../vulkan/appendices/VK_KHR_maintenance2.txt | 6 +- .../VK_KHR_shader_draw_parameters.txt | 28 ++++----- .../VK_KHR_shared_presentable_image.txt | 49 ++++++++------- .../VK_KHR_storage_buffer_storage_class.txt | 2 +- .../vulkan/appendices/VK_KHR_swapchain.txt | 29 ++++----- .../appendices/VK_KHR_variable_pointers.txt | 6 +- .../appendices/VK_KHR_wayland_surface.txt | 4 +- .../appendices/VK_KHR_win32_surface.txt | 26 ++++---- .../vulkan/appendices/VK_KHR_xcb_surface.txt | 6 +- .../vulkan/appendices/VK_KHR_xlib_surface.txt | 6 +- .../vulkan/appendices/VK_NN_vi_surface.txt | 6 +- .../VK_NVX_device_generated_commands.txt | 49 ++++++++------- .../VK_NVX_multiview_per_view_attributes.txt | 9 +-- .../appendices/VK_NV_external_memory.txt | 4 +- .../VK_NV_external_memory_win32.txt | 4 +- .../appendices/VK_NV_fill_rectangle.txt | 2 +- .../VK_NV_geometry_shader_passthrough.txt | 14 ++--- .../appendices/VK_NV_viewport_array2.txt | 2 +- .../appendices/VK_NV_viewport_swizzle.txt | 32 +++++----- doc/specs/vulkan/appendices/boilerplate.txt | 32 +++++----- doc/specs/vulkan/appendices/glossary.txt | 6 +- .../acquire_xlib_display.txt | 8 +-- .../vulkan/chapters/VK_EXT_debug_marker.txt | 4 +- .../VK_EXT_display_control/fence_events.txt | 2 +- .../VK_GOOGLE_display_timing/queries.txt | 6 +- .../platformCreateSurface_android.txt | 2 +- .../chapters/VK_KHR_display/display.txt | 14 ++--- .../VK_KHR_incremental_present/wsi.txt | 4 +- .../VK_KHR_shared_presentable_image/wsi.txt | 2 +- .../vulkan/chapters/VK_KHR_surface/wsi.txt | 8 +-- .../vulkan/chapters/VK_KHR_swapchain/wsi.txt | 10 ++-- .../platformCreateSurface_xcb.txt | 4 +- .../handle_permissions.txt | 3 +- doc/specs/vulkan/chapters/clears.txt | 4 +- doc/specs/vulkan/chapters/cmdbuffers.txt | 4 +- doc/specs/vulkan/chapters/copies.txt | 21 +++---- doc/specs/vulkan/chapters/descriptorsets.txt | 2 +- doc/specs/vulkan/chapters/devsandqueues.txt | 10 ++-- doc/specs/vulkan/chapters/drawing.txt | 50 ++++++++-------- doc/specs/vulkan/chapters/extensions.txt | 4 +- doc/specs/vulkan/chapters/features.txt | 60 +++++++++---------- doc/specs/vulkan/chapters/fragops.txt | 2 +- doc/specs/vulkan/chapters/fxvertex.txt | 2 +- doc/specs/vulkan/chapters/memory.txt | 4 +- doc/specs/vulkan/chapters/pipelines.txt | 8 +-- doc/specs/vulkan/chapters/primsrast.txt | 2 +- doc/specs/vulkan/chapters/renderpass.txt | 4 +- doc/specs/vulkan/chapters/resources.txt | 46 +++++++------- doc/specs/vulkan/chapters/samplers.txt | 6 +- doc/specs/vulkan/chapters/synchronization.txt | 6 +- doc/specs/vulkan/chapters/textures.txt | 8 +-- doc/specs/vulkan/style/markup.txt | 2 +- 70 files changed, 395 insertions(+), 377 deletions(-) diff --git a/ChangeLog.txt b/ChangeLog.txt index cdac781d..bd02575f 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt b/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt index 9feba101..e2148a81 100644 --- a/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt +++ b/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt b/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt index 2d792c30..b2a4054b 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt b/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt index f123fb11..b81eb6d0 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_global_priority.txt b/doc/specs/vulkan/appendices/VK_EXT_global_priority.txt index af412913..3140bb06 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_global_priority.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_global_priority.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt b/doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt index feaa26da..ee5b3065 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_sample_locations.txt b/doc/specs/vulkan/appendices/VK_EXT_sample_locations.txt index 812a5e0f..6cd6c089 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_sample_locations.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_sample_locations.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_ballot.txt b/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_ballot.txt index 0c5a0b10..13dccbe4 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_ballot.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_ballot.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_vote.txt b/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_vote.txt index 380fab62..73f9cb51 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_vote.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_shader_subgroup_vote.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_android_surface.txt b/doc/specs/vulkan/appendices/VK_KHR_android_surface.txt index 6579025d..95e77e4f 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_android_surface.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_android_surface.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_display.txt b/doc/specs/vulkan/appendices/VK_KHR_display.txt index 51295ce1..e8503929 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_display.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_display.txt @@ -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? diff --git a/doc/specs/vulkan/appendices/VK_KHR_display_swapchain.txt b/doc/specs/vulkan/appendices/VK_KHR_display_swapchain.txt index c7687dc6..05036629 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_display_swapchain.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_display_swapchain.txt @@ -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) diff --git a/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt b/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt index fc7eb53a..6c2d80e0 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_external_memory_win32.txt b/doc/specs/vulkan/appendices/VK_KHR_external_memory_win32.txt index 1f03bde6..67904bb2 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_external_memory_win32.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_external_memory_win32.txt @@ -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[] diff --git a/doc/specs/vulkan/appendices/VK_KHR_external_semaphore_win32.txt b/doc/specs/vulkan/appendices/VK_KHR_external_semaphore_win32.txt index 7540b942..a7301c03 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_external_semaphore_win32.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_external_semaphore_win32.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_get_memory_requirements2.txt b/doc/specs/vulkan/appendices/VK_KHR_get_memory_requirements2.txt index bef189a1..f2ab1a44 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_get_memory_requirements2.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_get_memory_requirements2.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_incremental_present.txt b/doc/specs/vulkan/appendices/VK_KHR_incremental_present.txt index d9510e38..94d3945c 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_incremental_present.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_incremental_present.txt @@ -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? diff --git a/doc/specs/vulkan/appendices/VK_KHR_maintenance1.txt b/doc/specs/vulkan/appendices/VK_KHR_maintenance1.txt index d72f41c5..4111d9f5 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_maintenance1.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_maintenance1.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_maintenance2.txt b/doc/specs/vulkan/appendices/VK_KHR_maintenance2.txt index c7881a12..0bc2bc16 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_maintenance2.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_maintenance2.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_shader_draw_parameters.txt b/doc/specs/vulkan/appendices/VK_KHR_shader_draw_parameters.txt index 36bedaae..538c1302 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_shader_draw_parameters.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_shader_draw_parameters.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_shared_presentable_image.txt b/doc/specs/vulkan/appendices/VK_KHR_shared_presentable_image.txt index 42f4d66d..af069c66 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_shared_presentable_image.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_shared_presentable_image.txt @@ -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? diff --git a/doc/specs/vulkan/appendices/VK_KHR_storage_buffer_storage_class.txt b/doc/specs/vulkan/appendices/VK_KHR_storage_buffer_storage_class.txt index 5f171f8f..e8e6c1bd 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_storage_buffer_storage_class.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_storage_buffer_storage_class.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt b/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt index 88670ea1..69e852a6 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_KHR_variable_pointers.txt b/doc/specs/vulkan/appendices/VK_KHR_variable_pointers.txt index ab0d7d92..2e90e2c0 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_variable_pointers.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_variable_pointers.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_wayland_surface.txt b/doc/specs/vulkan/appendices/VK_KHR_wayland_surface.txt index 98840f3a..6b24d3ef 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_wayland_surface.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_wayland_surface.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_win32_surface.txt b/doc/specs/vulkan/appendices/VK_KHR_win32_surface.txt index b499b726..0224c254 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_win32_surface.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_win32_surface.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_xcb_surface.txt b/doc/specs/vulkan/appendices/VK_KHR_xcb_surface.txt index 713c6353..ae1065f6 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_xcb_surface.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_xcb_surface.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_xlib_surface.txt b/doc/specs/vulkan/appendices/VK_KHR_xlib_surface.txt index de1162df..59ab1bb8 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_xlib_surface.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_xlib_surface.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_NN_vi_surface.txt b/doc/specs/vulkan/appendices/VK_NN_vi_surface.txt index 217c1949..4a4a5c8c 100644 --- a/doc/specs/vulkan/appendices/VK_NN_vi_surface.txt +++ b/doc/specs/vulkan/appendices/VK_NN_vi_surface.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt b/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt index b22f354c..f1c20fa9 100644 --- a/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt +++ b/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt @@ -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: diff --git a/doc/specs/vulkan/appendices/VK_NVX_multiview_per_view_attributes.txt b/doc/specs/vulkan/appendices/VK_NVX_multiview_per_view_attributes.txt index eb89543d..9d0117df 100644 --- a/doc/specs/vulkan/appendices/VK_NVX_multiview_per_view_attributes.txt +++ b/doc/specs/vulkan/appendices/VK_NVX_multiview_per_view_attributes.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_NV_external_memory.txt b/doc/specs/vulkan/appendices/VK_NV_external_memory.txt index f76e0710..cf98efba 100644 --- a/doc/specs/vulkan/appendices/VK_NV_external_memory.txt +++ b/doc/specs/vulkan/appendices/VK_NV_external_memory.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt b/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt index 2906712a..d00fb85a 100644 --- a/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt +++ b/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NV_fill_rectangle.txt b/doc/specs/vulkan/appendices/VK_NV_fill_rectangle.txt index 6113ea1c..4a4dc9af 100644 --- a/doc/specs/vulkan/appendices/VK_NV_fill_rectangle.txt +++ b/doc/specs/vulkan/appendices/VK_NV_fill_rectangle.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt b/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt index d3846986..74ecfb17 100644 --- a/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt +++ b/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt @@ -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: diff --git a/doc/specs/vulkan/appendices/VK_NV_viewport_array2.txt b/doc/specs/vulkan/appendices/VK_NV_viewport_array2.txt index 4ac50338..d2d06339 100644 --- a/doc/specs/vulkan/appendices/VK_NV_viewport_array2.txt +++ b/doc/specs/vulkan/appendices/VK_NV_viewport_array2.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt index 23ea3ec3..2b178aaf 100644 --- a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt +++ b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt @@ -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 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 - 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 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 diff --git a/doc/specs/vulkan/appendices/boilerplate.txt b/doc/specs/vulkan/appendices/boilerplate.txt index cb22fae7..f5350813 100644 --- a/doc/specs/vulkan/appendices/boilerplate.txt +++ b/doc/specs/vulkan/appendices/boilerplate.txt @@ -355,11 +355,11 @@ typedef (VKAPI_PTR *PFN_)(); // @refBegin VK_NO_STDINT_H Control definition of ++ 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 ++ 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 `++` 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]] @@ -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 | ++ -| +VK_KHR_mir_surface+ | +VK_USE_PLATFORM_MIR_KHR+ | Mir | ++ -| +VK_KHR_wayland_surface+ | +VK_USE_PLATFORM_WAYLAND_KHR+ | Wayland | ++ -| +VK_KHR_win32_surface+ | +VK_USE_PLATFORM_WIN32_KHR+ | Microsoft Windows | ++ -| +VK_KHR_xcb_surface+ | +VK_USE_PLATFORM_XCB_KHR+ | X Window System Xcb library | ++ -| +VK_KHR_xlib_surface+ | +VK_USE_PLATFORM_XLIB_KHR+ | X Window System Xlib library | ++ +| +VK_KHR_android_surface+ | dname:VK_USE_PLATFORM_ANDROID_KHR | Android Native | `++` +| +VK_KHR_mir_surface+ | dname:VK_USE_PLATFORM_MIR_KHR | Mir | `++` +| +VK_KHR_wayland_surface+ | dname:VK_USE_PLATFORM_WAYLAND_KHR | Wayland | `++` +| +VK_KHR_win32_surface+ | dname:VK_USE_PLATFORM_WIN32_KHR | Microsoft Windows | `++` +| +VK_KHR_xcb_surface+ | dname:VK_USE_PLATFORM_XCB_KHR | X Window System Xcb library | `++` +| +VK_KHR_xlib_surface+ | dname:VK_USE_PLATFORM_XLIB_KHR | X Window System Xlib library | `++` 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[] |==== diff --git a/doc/specs/vulkan/appendices/glossary.txt b/doc/specs/vulkan/appendices/glossary.txt index 07f9dd2a..8b97b3a7 100644 --- a/doc/specs/vulkan/appendices/glossary.txt +++ b/doc/specs/vulkan/appendices/glossary.txt @@ -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:: diff --git a/doc/specs/vulkan/chapters/VK_EXT_acquire_xlib_display/acquire_xlib_display.txt b/doc/specs/vulkan/chapters/VK_EXT_acquire_xlib_display/acquire_xlib_display.txt index 602a2e37..f5cc9c9e 100644 --- a/doc/specs/vulkan/chapters/VK_EXT_acquire_xlib_display/acquire_xlib_display.txt +++ b/doc/specs/vulkan/chapters/VK_EXT_acquire_xlib_display/acquire_xlib_display.txt @@ -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[] diff --git a/doc/specs/vulkan/chapters/VK_EXT_debug_marker.txt b/doc/specs/vulkan/chapters/VK_EXT_debug_marker.txt index b4b3f927..bab700ec 100644 --- a/doc/specs/vulkan/chapters/VK_EXT_debug_marker.txt +++ b/doc/specs/vulkan/chapters/VK_EXT_debug_marker.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 **** diff --git a/doc/specs/vulkan/chapters/VK_EXT_display_control/fence_events.txt b/doc/specs/vulkan/chapters/VK_EXT_display_control/fence_events.txt index c400ba7a..c9042a72 100644 --- a/doc/specs/vulkan/chapters/VK_EXT_display_control/fence_events.txt +++ b/doc/specs/vulkan/chapters/VK_EXT_display_control/fence_events.txt @@ -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[] diff --git a/doc/specs/vulkan/chapters/VK_GOOGLE_display_timing/queries.txt b/doc/specs/vulkan/chapters/VK_GOOGLE_display_timing/queries.txt index c921a4d8..987e2f11 100644 --- a/doc/specs/vulkan/chapters/VK_GOOGLE_display_timing/queries.txt +++ b/doc/specs/vulkan/chapters/VK_GOOGLE_display_timing/queries.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 diff --git a/doc/specs/vulkan/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt b/doc/specs/vulkan/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt index 1436c223..11c527f5 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/VK_KHR_display/display.txt b/doc/specs/vulkan/chapters/VK_KHR_display/display.txt index bf6e1578..be07f8c6 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_display/display.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_display/display.txt @@ -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. diff --git a/doc/specs/vulkan/chapters/VK_KHR_incremental_present/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_incremental_present/wsi.txt index 56987f5e..4a4d016f 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_incremental_present/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_incremental_present/wsi.txt @@ -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. -- diff --git a/doc/specs/vulkan/chapters/VK_KHR_shared_presentable_image/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_shared_presentable_image/wsi.txt index e28257ea..d8dc4b8a 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_shared_presentable_image/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_shared_presentable_image/wsi.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt index fc3bdcff..998be05a 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt @@ -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[] -- diff --git a/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt index 082fe3b6..c7d41187 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.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: diff --git a/doc/specs/vulkan/chapters/VK_KHR_xcb_surface/platformCreateSurface_xcb.txt b/doc/specs/vulkan/chapters/VK_KHR_xcb_surface/platformCreateSurface_xcb.txt index 65ae2fbc..f90d6ffc 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_xcb_surface/platformCreateSurface_xcb.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_xcb_surface/platformCreateSurface_xcb.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/VK_NV_external_memory_win32/handle_permissions.txt b/doc/specs/vulkan/chapters/VK_NV_external_memory_win32/handle_permissions.txt index 62dfe428..a539a312 100644 --- a/doc/specs/vulkan/chapters/VK_NV_external_memory_win32/handle_permissions.txt +++ b/doc/specs/vulkan/chapters/VK_NV_external_memory_win32/handle_permissions.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/clears.txt b/doc/specs/vulkan/chapters/clears.txt index 53499f33..9606ee35 100644 --- a/doc/specs/vulkan/chapters/clears.txt +++ b/doc/specs/vulkan/chapters/clears.txt @@ -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. ==== diff --git a/doc/specs/vulkan/chapters/cmdbuffers.txt b/doc/specs/vulkan/chapters/cmdbuffers.txt index a6cff279..bb192b1d 100644 --- a/doc/specs/vulkan/chapters/cmdbuffers.txt +++ b/doc/specs/vulkan/chapters/cmdbuffers.txt @@ -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_. diff --git a/doc/specs/vulkan/chapters/copies.txt b/doc/specs/vulkan/chapters/copies.txt index a3176939..06dc1551 100644 --- a/doc/specs/vulkan/chapters/copies.txt +++ b/doc/specs/vulkan/chapters/copies.txt @@ -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. diff --git a/doc/specs/vulkan/chapters/descriptorsets.txt b/doc/specs/vulkan/chapters/descriptorsets.txt index 913e341f..73bc83dc 100644 --- a/doc/specs/vulkan/chapters/descriptorsets.txt +++ b/doc/specs/vulkan/chapters/descriptorsets.txt @@ -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. diff --git a/doc/specs/vulkan/chapters/devsandqueues.txt b/doc/specs/vulkan/chapters/devsandqueues.txt index aba2e46e..1a05f613 100644 --- a/doc/specs/vulkan/chapters/devsandqueues.txt +++ b/doc/specs/vulkan/chapters/devsandqueues.txt @@ -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. diff --git a/doc/specs/vulkan/chapters/drawing.txt b/doc/specs/vulkan/chapters/drawing.txt index 76da2f4e..0e64155d 100644 --- a/doc/specs/vulkan/chapters/drawing.txt +++ b/doc/specs/vulkan/chapters/drawing.txt @@ -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 <> 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 <> @@ -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 <> 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 <> 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 <> 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 diff --git a/doc/specs/vulkan/chapters/extensions.txt b/doc/specs/vulkan/chapters/extensions.txt index ca1609c6..38277afc 100644 --- a/doc/specs/vulkan/chapters/extensions.txt +++ b/doc/specs/vulkan/chapters/extensions.txt @@ -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. diff --git a/doc/specs/vulkan/chapters/features.txt b/doc/specs/vulkan/chapters/features.txt index 4e04fcd9..17a7bb22 100644 --- a/doc/specs/vulkan/chapters/features.txt +++ b/doc/specs/vulkan/chapters/features.txt @@ -894,9 +894,9 @@ structure describe the following features: to execute atomically and in <>. 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, <>, 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, <>, 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. diff --git a/doc/specs/vulkan/chapters/fragops.txt b/doc/specs/vulkan/chapters/fragops.txt index 30b87d30..311c1cf9 100644 --- a/doc/specs/vulkan/chapters/fragops.txt +++ b/doc/specs/vulkan/chapters/fragops.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/fxvertex.txt b/doc/specs/vulkan/chapters/fxvertex.txt index 262e7605..55689ebb 100644 --- a/doc/specs/vulkan/chapters/fxvertex.txt +++ b/doc/specs/vulkan/chapters/fxvertex.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/memory.txt b/doc/specs/vulkan/chapters/memory.txt index 68e968ff..67be34dc 100644 --- a/doc/specs/vulkan/chapters/memory.txt +++ b/doc/specs/vulkan/chapters/memory.txt @@ -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 -<> +<> member of the slink:VkPhysicalDeviceLimits structure. If pname:maxMemoryAllocationCount is exceeded, fname:vkAllocateMemory will return ename:VK_ERROR_TOO_MANY_OBJECTS. diff --git a/doc/specs/vulkan/chapters/pipelines.txt b/doc/specs/vulkan/chapters/pipelines.txt index 9c5958e5..89581c61 100644 --- a/doc/specs/vulkan/chapters/pipelines.txt +++ b/doc/specs/vulkan/chapters/pipelines.txt @@ -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 <> * [[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. diff --git a/doc/specs/vulkan/chapters/primsrast.txt b/doc/specs/vulkan/chapters/primsrast.txt index 6cfe58aa..a2aef485 100644 --- a/doc/specs/vulkan/chapters/primsrast.txt +++ b/doc/specs/vulkan/chapters/primsrast.txt @@ -1183,7 +1183,7 @@ floating-point representation. ename:VK_DYNAMIC_STATE_DEPTH_BIAS dynamic state enabled * [[VUID-vkCmdSetDepthBias-depthBiasClamp-00790]] If the <> 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[] diff --git a/doc/specs/vulkan/chapters/renderpass.txt b/doc/specs/vulkan/chapters/renderpass.txt index 90b6cc2a..c9833477 100644 --- a/doc/specs/vulkan/chapters/renderpass.txt +++ b/doc/specs/vulkan/chapters/renderpass.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[] diff --git a/doc/specs/vulkan/chapters/resources.txt b/doc/specs/vulkan/chapters/resources.txt index 8fe1ff50..aceb3abe 100644 --- a/doc/specs/vulkan/chapters/resources.txt +++ b/doc/specs/vulkan/chapters/resources.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 diff --git a/doc/specs/vulkan/chapters/samplers.txt b/doc/specs/vulkan/chapters/samplers.txt index a58d32ef..c0657eb8 100644 --- a/doc/specs/vulkan/chapters/samplers.txt +++ b/doc/specs/vulkan/chapters/samplers.txt @@ -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 -<> +<> 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 diff --git a/doc/specs/vulkan/chapters/synchronization.txt b/doc/specs/vulkan/chapters/synchronization.txt index b2383278..03dbcf99 100644 --- a/doc/specs/vulkan/chapters/synchronization.txt +++ b/doc/specs/vulkan/chapters/synchronization.txt @@ -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[] diff --git a/doc/specs/vulkan/chapters/textures.txt b/doc/specs/vulkan/chapters/textures.txt index f29965de..9019ee53 100644 --- a/doc/specs/vulkan/chapters/textures.txt +++ b/doc/specs/vulkan/chapters/textures.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 -<>. +<>. The code:ConstOffset and code:Offset operands must: not be used with a sampler that enables <>. | 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.