Merge pull request #631 from krOoze/fix_random_extension_names
Cute up extension typography
This commit is contained in:
Jon Leech
GitHub
commit
ca0b221e15
|
|
@ -10,7 +10,7 @@ include::meta/VK_EXT_debug_marker.txt[]
|
|||
- Jon Ashburn, LunarG
|
||||
- Kyle Spagnoli, NVIDIA
|
||||
|
||||
The +VK_EXT_debug_marker+ extension is a device extension.
|
||||
The `VK_EXT_debug_marker` extension is a device extension.
|
||||
It introduces concepts of object naming and tagging, for better tracking of
|
||||
Vulkan objects, as well as additional commands for recording annotations of
|
||||
named sections of a workload to aid organisation and offline analysis in
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ include::meta/VK_EXT_debug_report.txt[]
|
|||
|
||||
Due to the nature of the Vulkan interface, there is very little error
|
||||
information available to the developer and application.
|
||||
By enabling optional validation layers and using the +VK_EXT_debug_report+
|
||||
By enabling optional validation layers and using the `VK_EXT_debug_report`
|
||||
extension, developers can: obtain much more detailed feedback on the
|
||||
application's use of Vulkan.
|
||||
This extension defines a way for layers and the implementation to call back
|
||||
|
|
@ -51,7 +51,7 @@ to the application for events of interest to the application.
|
|||
|
||||
=== Examples
|
||||
|
||||
+VK_EXT_debug_report+ allows an application to register multiple callbacks
|
||||
`VK_EXT_debug_report` allows an application to register multiple callbacks
|
||||
with the validation layers.
|
||||
Some callbacks may log the information to a file, others may cause a debug
|
||||
break point or other application defined behavior.
|
||||
|
|
@ -119,7 +119,7 @@ happens and the third will log warnings to stdout.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
In the initial release of the +VK_EXT_debug_report+ extension, the token
|
||||
In the initial release of the `VK_EXT_debug_report` extension, the token
|
||||
ename:VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT was used.
|
||||
Starting in version 2 of the extension branch,
|
||||
ename:VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT is used
|
||||
|
|
@ -130,7 +130,7 @@ The older enum is still available for backwards compatibility.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
In the initial release of the +VK_EXT_debug_report+ extension, the token
|
||||
In the initial release of the `VK_EXT_debug_report` extension, the token
|
||||
ename:VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_EXT was used.
|
||||
Starting in version 8 of the extension branch,
|
||||
ename:VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT is used
|
||||
|
|
|
|||
|
|
@ -37,16 +37,16 @@ None.
|
|||
=== Issues
|
||||
|
||||
1) Should this extension and its related platform-specific extensions
|
||||
leverage +VK_KHR_display+, or provide separate equivalent interfaces.
|
||||
leverage <<VK_KHR_display>>, or provide separate equivalent interfaces.
|
||||
|
||||
*RESOLVED*: Use +VK_KHR_display+ concepts and objects.
|
||||
+VK_KHR_display+ can be used to enumerate all displays on the system,
|
||||
*RESOLVED*: Use <<VK_KHR_display>> concepts and objects.
|
||||
<<VK_KHR_display>> can be used to enumerate all displays on the system,
|
||||
including those attached to/in use by a window system or native platform,
|
||||
but +VK_KHR_display_swapchain+ will fail to create a swapchain on in-use
|
||||
but <<VK_KHR_display_swapchain>> will fail to create a swapchain on in-use
|
||||
displays.
|
||||
This extension and its platform-specific children will allow applications to
|
||||
grab in-use displays away from window systems and/or native platforms,
|
||||
allowing them to be used with +VK_KHR_display_swapchain+.
|
||||
allowing them to be used with <<VK_KHR_display_swapchain>>.
|
||||
|
||||
2) Are separate calls needed to acquire displays and enable direct mode?
|
||||
|
||||
|
|
|
|||
|
|
@ -21,9 +21,9 @@ rejected if the fragment is within any of the operational discard rectangles
|
|||
|
||||
These discard rectangles operate orthogonally to the existing scissor test
|
||||
functionality.
|
||||
If the VK_KHX_device_group extension is enabled the discard rectangles can
|
||||
be different for each physical device in the device group by specifying the
|
||||
device mask and setting discard rectangle dynamic state.
|
||||
If the <<VK_KHX_device_group>> extension is enabled the discard rectangles
|
||||
can be different for each physical device in the device group by specifying
|
||||
the device mask and setting discard rectangle dynamic state.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ include::meta/VK_EXT_display_control.txt[]
|
|||
- Daniel Vetter, Intel
|
||||
|
||||
This extension defines a set of utility functions for use with the
|
||||
+VK_KHR_display+ and +VK_KHR_display_swapchain+ extensions.
|
||||
<<VK_KHR_display>> and <<VK_KHR_display_swapchain>> extensions.
|
||||
|
||||
=== New Enum Constants
|
||||
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@ ifdef::VK_NV_viewport_array2[]
|
|||
.Note
|
||||
====
|
||||
The code:ShaderViewportIndexLayerEXT capability is equivalent to the
|
||||
code:ShaderViewportIndexLayerNV capability added by
|
||||
<<VK_NV_viewport_array2,VK_NV_viewport_array2>>.
|
||||
code:ShaderViewportIndexLayerNV capability added by
|
||||
<<VK_NV_viewport_array2>>.
|
||||
====
|
||||
endif::VK_NV_viewport_array2[]
|
||||
|
||||
|
|
|
|||
|
|
@ -12,10 +12,10 @@ include::meta/VK_GOOGLE_display_timing.txt[]
|
|||
- Ian Elliott, Google
|
||||
- Jesse Hall, Google
|
||||
|
||||
This device extension allows an application that uses the +VK_KHR_swapchain+
|
||||
extension to obtain information about the presentation engine's display, to
|
||||
obtain timing information about each present, and to schedule a present to
|
||||
happen no earlier than a desired time.
|
||||
This device extension allows an application that uses the
|
||||
<<VK_KHR_swapchain>> extension to obtain information about the presentation
|
||||
engine's display, to obtain timing information about each present, and to
|
||||
schedule a present to happen no earlier than a desired time.
|
||||
An application can use this to minimize various visual anomalies (e.g.
|
||||
stuttering).
|
||||
|
||||
|
|
@ -68,11 +68,12 @@ None.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The example code for the this extension (like the +VK_KHR_surface+ and
|
||||
+VK_GOOGLE_display_timing+ extensions) is contained in the cube demo that is
|
||||
shipped with the official Khronos SDK, and is being kept up-to-date in that
|
||||
location (see:
|
||||
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c).
|
||||
The example code for the this extension (like the <<VK_KHR_surface>> and
|
||||
<<VK_GOOGLE_display_timing>> extensions) is contained in the cube demo that
|
||||
is shipped with the official Khronos SDK, and is being kept up-to-date in
|
||||
that location (see:
|
||||
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c
|
||||
).
|
||||
====
|
||||
|
||||
=== Version History
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ include::meta/VK_IMG_filter_cubic.txt[]
|
|||
*Contributors*::
|
||||
- Tobias Hector, Imagination Technologies
|
||||
|
||||
+VK_IMG_filter_cubic+ adds an additional, high quality cubic filtering mode
|
||||
`VK_IMG_filter_cubic` adds an additional, high quality cubic filtering mode
|
||||
to Vulkan, using a Catmull-Rom bicubic filter.
|
||||
Performing this kind of filtering can be done in a shader by using 16
|
||||
samples and a number of instructions, but this can be inefficient.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ include::meta/VK_KHR_16bit_storage.txt[]
|
|||
- David Neto, Google
|
||||
- John Kessenich, Google
|
||||
|
||||
The +VK_KHR_16bit_storage+ extension allows use of 16-bit types in shader
|
||||
The `VK_KHR_16bit_storage` extension allows use of 16-bit types in shader
|
||||
input and output interfaces, and push constant blocks.
|
||||
This extension introduces several new optional features which map to SPIR-V
|
||||
capabilities and allow access to 16-bit data in code:Block-decorated objects
|
||||
|
|
|
|||
|
|
@ -26,9 +26,9 @@ include::meta/VK_KHR_android_surface.txt[]
|
|||
- Jeff Vigil, Qualcomm
|
||||
- Chia-I Wu, LunarG
|
||||
|
||||
The +VK_KHR_android_surface+ extension is an instance extension.
|
||||
The `VK_KHR_android_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) that refers to an code:ANativeWindow,
|
||||
the <<VK_KHR_surface>> extension) that refers to an code:ANativeWindow,
|
||||
Android's native surface type.
|
||||
The code:ANativeWindow represents the producer endpoint of any buffer queue,
|
||||
regardless of consumer endpoint.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ include::meta/VK_KHR_descriptor_update_template.txt[]
|
|||
*IP Status*::
|
||||
No known IP claims.
|
||||
*Interactions and External Dependencies*::
|
||||
- Interacts with +VK_KHR_push_descriptor+
|
||||
- Interacts with <<VK_KHR_push_descriptor>>
|
||||
*Contributors*::
|
||||
- Jeff Bolz, NVIDIA
|
||||
- Michael Worcester, Imagination Technologies
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ work with which present queues?
|
|||
|
||||
*PROPOSED RESOLUTION*: No known hardware has such limitations, but
|
||||
determining such limitations is supported automatically using the existing
|
||||
+VK_KHR_surface+ and +VK_KHR_swapchain+ query mechanisms.
|
||||
<<VK_KHR_surface>> and <<VK_KHR_swapchain>> query mechanisms.
|
||||
|
||||
8) Should all presentation need to be done relative to an overlay plane, or
|
||||
can a display mode + display be used alone to target an output?
|
||||
|
|
@ -232,7 +232,7 @@ chain creation time, or on a per-present basis.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The example code for the +VK_KHR_display+ and +VK_KHR_display_swapchain+
|
||||
The example code for the `VK_KHR_display` and <<VK_KHR_display_swapchain>>
|
||||
extensions was removed from the appendix after revision 1.0.43.
|
||||
The display enumeration example code was ported to the cube demo that is
|
||||
shipped with the official Khronos SDK, and is being kept up-to-date in that
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ use for that image.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The example code for the +VK_KHR_display+ and +VK_KHR_display_swapchain+
|
||||
The example code for the <<VK_KHR_display>> and `VK_KHR_display_swapchain`
|
||||
extensions was removed from the appendix after revision 1.0.43.
|
||||
The display swapchain creation example code was ported to the cube demo that
|
||||
is shipped with the official Khronos SDK, and is being kept up-to-date in
|
||||
|
|
|
|||
|
|
@ -9,8 +9,8 @@ include::meta/VK_KHR_external_memory.txt[]
|
|||
*IP Status*::
|
||||
No known IP claims.
|
||||
*Interactions and External Dependencies*::
|
||||
- Interacts with +VK_KHR_dedicated_allocation+.
|
||||
- Interacts with +VK_NV_dedicated_allocation+.
|
||||
- Interacts with <<VK_KHR_dedicated_allocation>>.
|
||||
- Interacts with <<VK_NV_dedicated_allocation>>.
|
||||
*Contributors*::
|
||||
- Jason Ekstrand, Intel
|
||||
- Ian Elliot, Google
|
||||
|
|
@ -63,7 +63,7 @@ None.
|
|||
Vulkan instance boundaries?
|
||||
|
||||
*RESOLVED*: New device ID fields have been introduced by
|
||||
VK_KHR_external_memory_capabilities.
|
||||
<<VK_KHR_external_memory_capabilities>>.
|
||||
These fields, combined with the existing
|
||||
slink:VkPhysicalDeviceProperties::pname:driverVersion field can be used to
|
||||
identify compatible devices across processes, drivers, and APIs.
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ include::meta/VK_KHR_external_memory_capabilities.txt[]
|
|||
No known IP claims.
|
||||
*Interactions and External Dependencies*::
|
||||
- This extension is written against version 1.0 of the Vulkan API.
|
||||
- Requires +VK_KHR_get_physical_device_properties2+.
|
||||
- Interacts with +VK_KHR_dedicated_allocation+.
|
||||
- Interacts with +VK_NV_dedicated_allocation+.
|
||||
- Requires <<VK_KHR_get_physical_device_properties2>>.
|
||||
- Interacts with <<VK_KHR_dedicated_allocation>>.
|
||||
- Interacts with <<VK_NV_dedicated_allocation>>.
|
||||
*Contributors*::
|
||||
- Ian Elliot, Google
|
||||
- Jesse Hall, Google
|
||||
|
|
|
|||
|
|
@ -50,11 +50,11 @@ None.
|
|||
|
||||
1) What should this extension be named?
|
||||
|
||||
*RESOLVED*: VK_KHR_get_surface_capabilities2.
|
||||
*RESOLVED*: `VK_KHR_get_surface_capabilities2`.
|
||||
Other alternatives:
|
||||
|
||||
* VK_KHR_surface2
|
||||
* One extension, combined with VK_KHR_get_display_properties2
|
||||
* `VK_KHR_surface2`
|
||||
* One extension, combined with `VK_KHR_get_display_properties2`
|
||||
|
||||
2) Should additional WSI query functions be extended?
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ include::meta/VK_KHR_incremental_present.txt[]
|
|||
- Jeff Bolz, NVIDIA
|
||||
|
||||
This device extension extends slink:vkQueuePresentKHR, from the
|
||||
+VK_KHR_swapchain+ extension, allowing an application to specify a list of
|
||||
<<VK_KHR_swapchain>> extension, allowing an application to specify a list of
|
||||
rectangular, modified regions of each image to present.
|
||||
This should be used in situations where an application is only changing a
|
||||
small portion of the presentable images within a swapchain, since it enables
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ include::meta/VK_KHR_maintenance1.txt[]
|
|||
- Tobias Hector, Imagination Technologies
|
||||
- Tom Olson, ARM
|
||||
|
||||
+VK_KHR_maintenance1+ adds a collection of minor features that were
|
||||
`VK_KHR_maintenance1` adds a collection of minor features that were
|
||||
intentionally left out or overlooked from the original Vulkan 1.0 release.
|
||||
|
||||
The new features are as follows:
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ include::meta/VK_KHR_maintenance2.txt[]
|
|||
- Neil Henning, Codeplay
|
||||
- Piers Daniell, NVIDIA
|
||||
|
||||
+VK_KHR_maintenance2+ adds a collection of minor features that were
|
||||
`VK_KHR_maintenance2` adds a collection of minor features that were
|
||||
intentionally left out or overlooked from the original Vulkan 1.0 release.
|
||||
|
||||
The new features are as follows:
|
||||
|
|
|
|||
|
|
@ -27,9 +27,9 @@ include::meta/VK_KHR_mir_surface.txt[]
|
|||
- Chia-I Wu, LunarG
|
||||
|
||||
|
||||
The +VK_KHR_mir_surface+ extension is an instance extension.
|
||||
The `VK_KHR_mir_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface extension+) that refers to a Mir surface, as well as a
|
||||
the <<VK_KHR_surface>> extension) that refers to a Mir surface, as well as a
|
||||
query to determine support for rendering to the windows desktop.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ include::meta/VK_KHR_relaxed_block_layout.txt[]
|
|||
*Contributors*::
|
||||
- John Kessenich, Google
|
||||
|
||||
The +VK_KHR_relaxed_block_layout+ extension allows implementations to
|
||||
The `VK_KHR_relaxed_block_layout` extension allows implementations to
|
||||
indicate they can support more variation in block code:Offset decorations.
|
||||
For example, placing a vector of three floats at an offset of 16*N + 4.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ include::meta/VK_KHR_sampler_mirror_clamp_to_edge.txt[]
|
|||
*Contributors*::
|
||||
- Tobias Hector, Imagination Technologies
|
||||
|
||||
+VK_KHR_sampler_mirror_clamp_to_edge+ extends the set of sampler address
|
||||
`VK_KHR_sampler_mirror_clamp_to_edge` extends the set of sampler address
|
||||
modes to include an additional mode
|
||||
(ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE) that effectively uses a
|
||||
texture map twice as large as the original image in which the additional
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ include::meta/VK_KHR_sampler_ycbcr_conversion.txt[]
|
|||
*IP Status*::
|
||||
No known IP claims.
|
||||
*Interactions and External Dependencies*::
|
||||
- This extension interacts with +VK_EXT_debug_report+
|
||||
- This extension interacts with <<VK_EXT_debug_report>>
|
||||
*Contributors*::
|
||||
- Andrew Garrard, Samsung Electronics
|
||||
- Tobias Hector, Imagination Technologies
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ include::meta/VK_KHR_shared_presentable_image.txt[]
|
|||
- Cass Everitt, Oculus
|
||||
- Johannes Van Waveren, Oculus
|
||||
|
||||
This extension extends +VK_KHR_swapchain+ to enable creation of a shared
|
||||
This extension extends <<VK_KHR_swapchain>> to enable creation of a shared
|
||||
presentable image.
|
||||
This allows the application to use the image while the presention engine is
|
||||
accessing it, in order to reduce the latency between rendering and
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ include::meta/VK_KHR_surface.txt[]
|
|||
- Chia-I Wu, LunarG
|
||||
- Jason Ekstrand, Intel
|
||||
|
||||
The +VK_KHR_surface+ extension is an instance extension.
|
||||
The `VK_KHR_surface` extension is an instance extension.
|
||||
It introduces slink:VkSurfaceKHR objects, which abstract native platform
|
||||
surface or window objects for use with Vulkan.
|
||||
It also provides a way to determine whether a queue family in a physical
|
||||
|
|
@ -31,7 +31,7 @@ device supports presenting to particular surface.
|
|||
Separate extensions for each each platform provide the mechanisms for
|
||||
creating slink:VkSurfaceKHR objects, but once created they may be used in
|
||||
this and other platform-independent extensions, in particular the
|
||||
+VK_KHR_swapchain+ extension.
|
||||
<<VK_KHR_swapchain>> extension.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
@ -68,8 +68,8 @@ this and other platform-independent extensions, in particular the
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The example code for the +VK_KHR_surface+ and +VK_KHR_swapchain+ extensions
|
||||
was removed from the appendix after revision 1.0.29.
|
||||
The example code for the `VK_KHR_surface` and <<VK_KHR_swapchain>>
|
||||
extensions was removed from the appendix after revision 1.0.29.
|
||||
This WSI example code was ported to the cube demo that is shipped with the
|
||||
official Khronos SDK, and is being kept up-to-date in that location (see:
|
||||
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c).
|
||||
|
|
@ -94,7 +94,7 @@ section of the desktop they exist on.
|
|||
2) Should the flink:vkGetPhysicalDeviceSurfaceCapabilitiesKHR,
|
||||
flink:vkGetPhysicalDeviceSurfaceFormatsKHR, and
|
||||
flink:vkGetPhysicalDeviceSurfacePresentModesKHR functions from
|
||||
+VK_KHR_swapchain+ be modified to operate on physical devices and moved to
|
||||
<<VK_KHR_swapchain>> be modified to operate on physical devices and moved to
|
||||
this extension to implement the resolution of issue 1?
|
||||
|
||||
*RESOLVED*: No, separate query functions are needed, as the purposes served
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ include::meta/VK_KHR_swapchain.txt[]
|
|||
- Matthaeus G. Chajdas, AMD
|
||||
- Ray Smith, ARM
|
||||
|
||||
The +VK_KHR_swapchain+ extension is the device-level companion to the
|
||||
+VK_KHR_surface+ extension.
|
||||
The `VK_KHR_swapchain` extension is the device-level companion to the
|
||||
<<VK_KHR_surface>> extension.
|
||||
It introduces slink:VkSwapchainKHR objects, which provide the ability to
|
||||
present rendering results to a surface.
|
||||
|
||||
|
|
@ -435,8 +435,8 @@ requirement is only sensible at the swapchain level.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The example code for the +VK_KHR_surface+ and +VK_KHR_swapchain+ extensions
|
||||
was removed from the appendix after revision 1.0.29.
|
||||
The example code for the <<VK_KHR_surface>> and `VK_KHR_swapchain`
|
||||
extensions was removed from the appendix after revision 1.0.29.
|
||||
This WSI example code was ported to the cube demo that is shipped with the
|
||||
official Khronos SDK, and is being kept up-to-date in that location (see:
|
||||
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c).
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ include::meta/VK_KHR_variable_pointers.txt[]
|
|||
- Jason Ekstrand, Intel
|
||||
- Jesse Hall, Google
|
||||
|
||||
The +VK_KHR_variable_pointers+ extension allows implementations to indicate
|
||||
The `VK_KHR_variable_pointers` extension allows implementations to indicate
|
||||
their level of support for the +SPV_KHR_variable_pointers+ SPIR-V extension.
|
||||
The SPIR-V extension allows shader modules to use invocation-private
|
||||
pointers into uniform and/or storage buffers, where the pointer values can
|
||||
|
|
|
|||
|
|
@ -26,10 +26,11 @@ include::meta/VK_KHR_wayland_surface.txt[]
|
|||
- Jeff Vigil, Qualcomm
|
||||
- Chia-I Wu, LunarG
|
||||
|
||||
The +VK_KHR_wayland_surface+ extension is an instance extension.
|
||||
The `VK_KHR_wayland_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) that refers to a Wayland code:wl_surface, as
|
||||
well as a query to determine support for rendering to a Wayland compositor.
|
||||
the <<VK_KHR_surface>> extension) that refers to a Wayland code:wl_surface,
|
||||
as well as a query to determine support for rendering to a Wayland
|
||||
compositor.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
|
|||
|
|
@ -26,10 +26,10 @@ include::meta/VK_KHR_win32_surface.txt[]
|
|||
- Jeff Vigil, Qualcomm
|
||||
- Chia-I Wu, LunarG
|
||||
|
||||
The +VK_KHR_win32_surface+ extension is an instance extension.
|
||||
The `VK_KHR_win32_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) that refers to a Win32 code:HWND, as well as
|
||||
a query to determine support for rendering to the windows desktop.
|
||||
the <<VK_KHR_surface>> extension) that refers to a Win32 code:HWND, as well
|
||||
as a query to determine support for rendering to the windows desktop.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
|
|||
|
|
@ -26,10 +26,10 @@ include::meta/VK_KHR_xcb_surface.txt[]
|
|||
- Jeff Vigil, Qualcomm
|
||||
- Chia-I Wu, LunarG
|
||||
|
||||
The +VK_KHR_xcb_surface+ extension is an instance extension.
|
||||
The `VK_KHR_xcb_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface extension+) that refers to an X11 code:Window, using the
|
||||
XCB client-side library, as well as a query to determine support for
|
||||
the <<VK_KHR_surface>> extension) that refers to an X11 code:Window, using
|
||||
the XCB client-side library, as well as a query to determine support for
|
||||
rendering via XCB.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -26,10 +26,10 @@ include::meta/VK_KHR_xlib_surface.txt[]
|
|||
- Jeff Vigil, Qualcomm
|
||||
- Chia-I Wu, LunarG
|
||||
|
||||
The +VK_KHR_xlib_surface+ extension is an instance extension.
|
||||
The `VK_KHR_xlib_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) that refers to an X11 code:Window, using the
|
||||
Xlib client-side library, as well as a query to determine support for
|
||||
the <<VK_KHR_surface>> extension) that refers to an X11 code:Window, using
|
||||
the Xlib client-side library, as well as a query to determine support for
|
||||
rendering via Xlib.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ include::meta/VK_KHX_device_group.txt[]
|
|||
|
||||
This extension provides functionality to use a logical device that consists
|
||||
of multiple physical devices, as created with the
|
||||
+VK_KHX_device_group_creation+ extension.
|
||||
<<VK_KHX_device_group_creation>> extension.
|
||||
A device group can allocate memory across the subdevices, bind memory from
|
||||
one subdevice to a resource on another subdevice, record command buffers
|
||||
where some work executes on an arbitrary subset of the subdevices, and
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ This extension provides instance-level commands to enumerate groups of
|
|||
physical devices, and to create a logical device from a subset of one of
|
||||
those groups.
|
||||
Such a logical device can then be used with new features in the
|
||||
VK_KHX_device_group extension.
|
||||
<<VK_KHX_device_group>> extension.
|
||||
|
||||
=== New Object Types
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ include::meta/VK_MVK_ios_surface.txt[]
|
|||
*Contributors*::
|
||||
- Bill Hollings, The Brenwill Workshop Ltd.
|
||||
|
||||
The +VK_MVK_ios_surface+ extension is an instance extension.
|
||||
The `VK_MVK_ios_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) that refers to a code:UIView, the native
|
||||
the <<VK_KHR_surface>> extension) that refers to a code:UIView, the native
|
||||
surface type of iOS, which is underpinned by a code:CAMetalLayer, to support
|
||||
rendering to the surface using Apple's Metal framework.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ include::meta/VK_MVK_macos_surface.txt[]
|
|||
*Contributors*::
|
||||
- Bill Hollings, The Brenwill Workshop Ltd.
|
||||
|
||||
The +VK_MVK_macos_surface+ extension is an instance extension.
|
||||
The `VK_MVK_macos_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) that refers to an code:NSView, the native
|
||||
the <<VK_KHR_surface>> extension) that refers to an code:NSView, the native
|
||||
surface type of macOS, which is underpinned by a code:CAMetalLayer, to
|
||||
support rendering to the surface using Apple's Metal framework.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ include::meta/VK_NN_vi_surface.txt[]
|
|||
- Yasuhiro Yoshioka, Nintendo
|
||||
- Daniel Koch, NVIDIA
|
||||
|
||||
The +VK_NN_vi_surface+ extension is an instance extension.
|
||||
The `VK_NN_vi_surface` extension is an instance extension.
|
||||
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
|
||||
the +VK_KHR_surface+ extension) associated with an
|
||||
the <<VK_KHR_surface>> extension) associated with an
|
||||
code:nn::code:vi::code:Layer.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ Extending elink:VkAccessFlagBits:
|
|||
|
||||
1) How to name this extension ?
|
||||
|
||||
*RESOLVED*: +VK_NVX_device_generated_commands+
|
||||
*RESOLVED*: `VK_NVX_device_generated_commands`
|
||||
|
||||
As usual one of the hardest issues ;)
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@ include::meta/VK_NVX_multiview_per_view_attributes.txt[]
|
|||
SPIR-V extension.
|
||||
- This extension requires the +GL_NVX_multiview_per_view_attributes+
|
||||
extension for GLSL source languages.
|
||||
- This extension interacts with
|
||||
<<VK_NV_viewport_array2,VK_NV_viewport_array2>>.
|
||||
- This extension interacts with <<VK_NV_viewport_array2>>.
|
||||
*Contributors*::
|
||||
- Jeff Bolz, NVIDIA
|
||||
- Daniel Koch, NVIDIA
|
||||
|
|
@ -42,7 +41,7 @@ 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.
|
||||
|
||||
If +VK_NV_viewport_array2+ is not also supported and enabled, the per-view
|
||||
If <<VK_NV_viewport_array2>> is not also supported and enabled, the per-view
|
||||
viewport mask must: not be used.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ include::meta/VK_NV_external_memory_capabilities.txt[]
|
|||
*IP Status*::
|
||||
No known IP claims.
|
||||
*Interactions and External Dependencies*::
|
||||
- Interacts with +VK_KHR_dedicated_allocation+.
|
||||
- Interacts with +VK_NV_dedicated_allocation+.
|
||||
- Interacts with <<VK_KHR_dedicated_allocation>>.
|
||||
- Interacts with <<VK_NV_dedicated_allocation>>.
|
||||
*Contributors*::
|
||||
- James Jones, NVIDIA
|
||||
|
||||
|
|
|
|||
|
|
@ -60,15 +60,16 @@ must happen prior to the viewport transform.
|
|||
In particular, it needs to be performed before clipping and perspective
|
||||
division.
|
||||
|
||||
The viewport mask expansion (NV_viewport_array2) and the viewport swizzle
|
||||
could potentially be performed before or after transform feedback, but
|
||||
feeding back several viewports worth of primitives with different swizzles
|
||||
doesn't seem particularly useful.
|
||||
The viewport mask expansion (<<VK_NV_viewport_array2>>) and the viewport
|
||||
swizzle could potentially be performed before or after transform feedback,
|
||||
but feeding back several viewports worth of primitives with different
|
||||
swizzles doesn't seem particularly useful.
|
||||
This specification applies the viewport mask and swizzle after transform
|
||||
feedback, and makes primitive queries only count each primitive once.
|
||||
|
||||
2) Any interesting examples of how this extension, NV_viewport_array2, and
|
||||
NV_geometry_shader_passthrough can be used together in practice?
|
||||
2) Any interesting examples of how this extension,
|
||||
<<VK_NV_viewport_array2>>, and <<VK_NV_geometry_shader_passthrough>> can be
|
||||
used together in practice?
|
||||
|
||||
**RESOLVED**: One interesting use case for this extension is for single-pass
|
||||
rendering to a cubemap.
|
||||
|
|
|
|||
|
|
@ -389,20 +389,20 @@ the macro is ``#define``d are shown in the
|
|||
[options="header"]
|
||||
|====
|
||||
| Extension Name | Required Compile Time Symbol | Window System Name | External Header Files Used
|
||||
| +VK_KHR_android_surface+ | dname:VK_USE_PLATFORM_ANDROID_KHR | Android Native | `+<android/native_window.h>+`
|
||||
| +VK_KHR_mir_surface+ | dname:VK_USE_PLATFORM_MIR_KHR | Mir | `+<mir_toolkit/client_types.h>+`
|
||||
| +VK_KHR_wayland_surface+ | dname:VK_USE_PLATFORM_WAYLAND_KHR | Wayland | `+<wayland-client.h>+`
|
||||
| +VK_KHR_win32_surface+ | dname:VK_USE_PLATFORM_WIN32_KHR | Microsoft Windows | `+<windows.h>+`
|
||||
| +VK_KHR_xcb_surface+ | dname:VK_USE_PLATFORM_XCB_KHR | X Window System Xcb library | `+<xcb/xcb.h>+`
|
||||
| +VK_KHR_xlib_surface+ | dname:VK_USE_PLATFORM_XLIB_KHR | X Window System Xlib library | `+<X11/Xlib.h>+`
|
||||
| <<VK_KHR_android_surface>> | dname:VK_USE_PLATFORM_ANDROID_KHR | Android Native | `+<android/native_window.h>+`
|
||||
| <<VK_KHR_mir_surface>> | dname:VK_USE_PLATFORM_MIR_KHR | Mir | `+<mir_toolkit/client_types.h>+`
|
||||
| <<VK_KHR_wayland_surface>> | dname:VK_USE_PLATFORM_WAYLAND_KHR | Wayland | `+<wayland-client.h>+`
|
||||
| <<VK_KHR_win32_surface>> | dname:VK_USE_PLATFORM_WIN32_KHR | Microsoft Windows | `+<windows.h>+`
|
||||
| <<VK_KHR_xcb_surface>> | dname:VK_USE_PLATFORM_XCB_KHR | X Window System Xcb library | `+<xcb/xcb.h>+`
|
||||
| <<VK_KHR_xlib_surface>> | dname:VK_USE_PLATFORM_XLIB_KHR | X Window System Xlib library | `+<X11/Xlib.h>+`
|
||||
ifdef::VK_MVK_ios_surface[]
|
||||
| +VK_MVK_ios_surface+ | dname: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+ | dname: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+ | dname:VK_USE_PLATFORM_VI_NN | VI | None
|
||||
| <<VK_NN_vi_surface>> | dname:VK_USE_PLATFORM_VI_NN | VI | None
|
||||
endif::VK_NN_vi_surface[]
|
||||
|====
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Adjacent Vertex::
|
|||
ifdef::VK_EXT_blend_operation_advanced[]
|
||||
Advanced Blend Operation::
|
||||
Blending performed using one of the blend operation enums introduced by
|
||||
the +VK_EXT_blend_operation_advanced+ extension.
|
||||
the <<VK_EXT_blend_operation_advanced>> extension.
|
||||
See <<framebuffer-blend-advanced, Advanced Blending Operations>>.
|
||||
endif::VK_EXT_blend_operation_advanced[]
|
||||
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
[open,refpage='VkPresentTimesInfoGOOGLE',desc='The earliest time each image should be presented',type='structs']
|
||||
--
|
||||
|
||||
When the +VK_GOOGLE_display_timing+ extension is enabled, additional fields
|
||||
can: be specified that allow an application to specify the earliest time
|
||||
that an image should be displayed.
|
||||
When the <<VK_GOOGLE_display_timing>> extension is enabled, additional
|
||||
fields can: be specified that allow an application to specify the earliest
|
||||
time that an image should be displayed.
|
||||
This allows an application to avoid stutter that is caused by an image being
|
||||
displayed earlier than planned.
|
||||
Such stuttering can occur with both fixed and variable-refresh-rate
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Applications also need to tell the presentation engine to display an image
|
|||
no sooner than a given time.
|
||||
This can allow the application's animation to look smooth to the user, with
|
||||
no stuttering.
|
||||
The +VK_GOOGLE_display_timing+ extension allows an application to satisfy
|
||||
The <<VK_GOOGLE_display_timing>> extension allows an application to satisfy
|
||||
these needs.
|
||||
|
||||
The presentation engine's display typically refreshes the pixels that are
|
||||
|
|
@ -213,7 +213,7 @@ satisfactory.
|
|||
|
||||
--
|
||||
|
||||
The full +VK_GOOGLE_display_timing+ extension semantics are described for
|
||||
The full <<VK_GOOGLE_display_timing>> extension semantics are described for
|
||||
swapchains created with ename:VK_PRESENT_MODE_FIFO_KHR.
|
||||
For example, non-zero values of
|
||||
sname:VkPresentTimeGOOGLE::pname:desiredPresentTime must: be honored, and
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
[open,refpage='VkPhysicalDevice16BitStorageFeaturesKHR',desc='Structure describing features supported by VK_KHR_16bit_storage',type='structs']
|
||||
--
|
||||
|
||||
To query features additionally supported by the +VK_KHR_16bit_storage+
|
||||
To query features additionally supported by the <<VK_KHR_16bit_storage>>
|
||||
extension, call flink:vkGetPhysicalDeviceFeatures2KHR with a
|
||||
sname:VkPhysicalDevice16BitStorageFeaturesKHR structure included in the
|
||||
pname:pNext chain of its pname:pFeatures parameter.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ In some environments applications can: also present Vulkan rendering
|
|||
directly to display devices without using an intermediate windowing system.
|
||||
This can: be useful for embedded applications, or implementing the
|
||||
rendering/presentation backend of a windowing system using Vulkan.
|
||||
The +VK_KHR_display+ extension provides the functionality necessary to
|
||||
The <<VK_KHR_display>> extension provides the functionality necessary to
|
||||
enumerate display devices and create sname:VkSurfaceKHR objects that target
|
||||
displays.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
[open,refpage='vkCreateSharedSwapchainsKHR',desc='Create multiple swapchains that share presentable images',type='protos']
|
||||
--
|
||||
|
||||
When the +VK_KHR_display_swapchain+ extension is enabled, multiple
|
||||
When the <<VK_KHR_display_swapchain>> extension is enabled, multiple
|
||||
swapchains that share presentable images are created by calling:
|
||||
|
||||
include::../../api/protos/vkCreateSharedSwapchainsKHR.txt[]
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
[[display_swapchain_present,display_swapchain_present]]
|
||||
|
||||
When the +VK_KHR_display_swapchain+ extension is enabled additional fields
|
||||
When the <<VK_KHR_display_swapchain>> extension is enabled additional fields
|
||||
can: be specified when presenting an image to a swapchain by setting
|
||||
slink:VkPresentInfoKHR::pname:pNext to point to an instance of the
|
||||
slink:VkDisplayPresentInfoKHR structure.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
[open,refpage='VkPresentRegionsKHR',desc='Structure hint of rectangular regions changed by vkQueuePresentKHR',type='structs']
|
||||
--
|
||||
|
||||
When the +VK_KHR_incremental_present+ extension is enabled, additional
|
||||
When the <<VK_KHR_incremental_present>> extension is enabled, additional
|
||||
fields can: be specified that allow an application to specify that only
|
||||
certain rectangular regions of the presentable images of a swapchain are
|
||||
changed.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ they are intended for.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The +VK_KHR_shared_presentable_image+ extension does not provide
|
||||
The <<VK_KHR_shared_presentable_image>> extension does not provide
|
||||
functionality for determining the timing of the presentation engine's
|
||||
refresh cycles.
|
||||
====
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ which are represented by sname:VkSurfaceKHR handles:
|
|||
|
||||
include::../../api/handles/VkSurfaceKHR.txt[]
|
||||
|
||||
The +VK_KHR_surface+ extension declares the sname:VkSurfaceKHR object, and
|
||||
The <<VK_KHR_surface>> extension declares the sname:VkSurfaceKHR object, and
|
||||
provides a function for destroying sname:VkSurfaceKHR objects.
|
||||
Separate platform-specific extensions each provide a function for creating a
|
||||
sname:VkSurfaceKHR object for the respective platform.
|
||||
|
|
@ -121,7 +121,7 @@ endif::VK_NN_vi_surface[]
|
|||
=== Platform-Independent Information
|
||||
|
||||
Once created, sname:VkSurfaceKHR objects can: be used in this and other
|
||||
extensions, in particular the +VK_KHR_swapchain+ extension.
|
||||
extensions, in particular the <<VK_KHR_swapchain>> extension.
|
||||
|
||||
Several WSI functions return ename:VK_ERROR_SURFACE_LOST_KHR if the surface
|
||||
becomes no longer available.
|
||||
|
|
@ -892,7 +892,7 @@ In this case, the application can: use any valid elink:VkFormat value.
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
In the initial release of the +VK_KHR_surface+ and +VK_KHR_swapchain+
|
||||
In the initial release of the <<VK_KHR_surface>> and <<VK_KHR_swapchain>>
|
||||
extensions, the token ename:VK_COLORSPACE_SRGB_NONLINEAR_KHR was used.
|
||||
Starting in the 2016-05-13 updates to the extension branches, matching
|
||||
release 1.0.13 of the core API specification,
|
||||
|
|
|
|||
|
|
@ -725,7 +725,7 @@ ifdef::VK_KHR_maintenance1[]
|
|||
ifdef::VK_AMD_negative_viewport_height[]
|
||||
* [[VUID-VkDeviceCreateInfo-ppEnabledExtensionNames-00374]]
|
||||
pname:ppEnabledExtensionNames must: not contain both
|
||||
code:VK_KHR_maintenance1 and code:VK_AMD_negative_viewport_height
|
||||
<<VK_KHR_maintenance1>> and <<VK_AMD_negative_viewport_height>>
|
||||
endif::VK_AMD_negative_viewport_height[]
|
||||
endif::VK_KHR_maintenance1[]
|
||||
****
|
||||
|
|
|
|||
|
|
@ -343,10 +343,10 @@ Vulkan 1.0 requires all new physical-device-level extension functionality to
|
|||
be structured within an instance extension.
|
||||
ifdef::VK_KHR_get_physical_device_properties2[]
|
||||
In order to avoid using an instance extension, which often requires loader
|
||||
support, the +VK_KHR_get_physical_device_properties2+ extension allows
|
||||
support, the <<VK_KHR_get_physical_device_properties2>> extension allows
|
||||
physical-device-level extension functionality to be implemented within
|
||||
device extensions (which must: depend on the
|
||||
+VK_KHR_get_physical_device_properties2+ extension).
|
||||
`VK_KHR_get_physical_device_properties2` extension).
|
||||
endif::VK_KHR_get_physical_device_properties2[]
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ The features and limits are reported via basic structures (that is
|
|||
slink:VkPhysicalDeviceFeatures and slink:VkPhysicalDeviceLimits), as well as
|
||||
extensible structures (sname:VkPhysicalDeviceFeatures2KHR and
|
||||
sname:VkPhysicalDeviceProperties2KHR) which were added in
|
||||
code:VK_KHR_get_physical_device_properties2.
|
||||
<<VK_KHR_get_physical_device_properties2>>.
|
||||
When new features or limits are added in future Vulkan version or
|
||||
extensions, each extension should: introduce one new feature structure
|
||||
and/or limit structure (as needed).
|
||||
|
|
@ -920,9 +920,8 @@ All Vulkan graphics implementations must: support the following features:
|
|||
|
||||
* pname:robustBufferAccess.
|
||||
ifdef::VK_KHR_variable_pointers[]
|
||||
* pname:variablePointersStorageBuffer, if the
|
||||
<<VK_KHR_variable_pointers,+VK_KHR_variable_pointers+>> extension is
|
||||
supported.
|
||||
* pname:variablePointersStorageBuffer, if the <<VK_KHR_variable_pointers>>
|
||||
extension is supported.
|
||||
endif::VK_KHR_variable_pointers[]
|
||||
|
||||
All other features are not required: by the Specification.
|
||||
|
|
@ -2111,11 +2110,11 @@ whether or not the feature is enabled.
|
|||
| basetype:VkDeviceSize | pname:optimalBufferCopyRowPitchAlignment | -
|
||||
| basetype:VkDeviceSize | pname:nonCoherentAtomSize | -
|
||||
ifdef::VK_EXT_discard_rectangles[]
|
||||
| code:uint32_t | pname:maxDiscardRectangles | +VK_EXT_discard_rectangles+
|
||||
| code:uint32_t | pname:maxDiscardRectangles | <<VK_EXT_discard_rectangles>>
|
||||
endif::VK_EXT_discard_rectangles[]
|
||||
ifdef::VK_EXT_sampler_filter_minmax[]
|
||||
| basetype:VkBool32 | pname:filterMinmaxSingleComponentFormats | VK_EXT_sampler_filter_minmax
|
||||
| basetype:VkBool32 | pname:filterMinmaxImageComponentMapping | VK_EXT_sampler_filter_minmax
|
||||
| basetype:VkBool32 | pname:filterMinmaxSingleComponentFormats | <<VK_EXT_sampler_filter_minmax>>
|
||||
| basetype:VkBool32 | pname:filterMinmaxImageComponentMapping | <<VK_EXT_sampler_filter_minmax>>
|
||||
endif::VK_EXT_sampler_filter_minmax[]
|
||||
|====
|
||||
|
||||
|
|
@ -5216,9 +5215,7 @@ include::../api/structs/VkTextureLODGatherFormatPropertiesAMD.txt[]
|
|||
* pname:pNext is `NULL`.
|
||||
* pname:supportsTextureGatherLODBiasAMD tells if the image format can be
|
||||
used with texture gather bias/LOD functions, as introduced by the
|
||||
ename:VK_AMD_texture_gather_bias_lod extension.
|
||||
(see
|
||||
<<VK_AMD_texture_gather_bias_lod,+VK_AMD_texture_gather_bias_lod+>>).
|
||||
<<VK_AMD_texture_gather_bias_lod>> extension.
|
||||
This field is set by the implementation.
|
||||
User-specified value is ignored.
|
||||
|
||||
|
|
@ -5441,7 +5438,7 @@ include::../api/enums/VkExternalMemoryFeatureFlagBitsKHR.txt[]
|
|||
|
||||
* ename:VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_KHR specifies that
|
||||
images or buffers created with the specified parameters and handle type
|
||||
must: use the mechanisms defined in the +VK_NV_dedicated_allocation+
|
||||
must: use the mechanisms defined in the <<VK_NV_dedicated_allocation>>
|
||||
extension to create (or import) a dedicated allocation for the image or
|
||||
buffer.
|
||||
* ename:VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR specifies that
|
||||
|
|
|
|||
|
|
@ -1027,7 +1027,7 @@ ifdef::VK_NV_glsl_shader[]
|
|||
* ename:VK_ERROR_INVALID_SHADER_NV One or more shaders failed to compile
|
||||
or link.
|
||||
More details are reported back to the application via
|
||||
+VK_EXT_debug_report+ if enabled.
|
||||
<<VK_EXT_debug_report>> if enabled.
|
||||
endif::VK_NV_glsl_shader[]
|
||||
ifdef::VK_KHR_maintenance1[]
|
||||
* ename:VK_ERROR_OUT_OF_POOL_MEMORY_KHR A pool memory allocation has
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ ifdef::VK_KHR_get_physical_device_properties2[]
|
|||
|
||||
=== Extending Physical Device From Device Extensions
|
||||
|
||||
When the +VK_KHR_get_physical_device_properties2+ extension is enabled,
|
||||
When the <<VK_KHR_get_physical_device_properties2>> extension is enabled,
|
||||
physical device extension commands and structures can: be used with a
|
||||
physical device if the corresponding extension is enumerated by
|
||||
flink:vkEnumerateDeviceExtensionProperties for that physical device, even
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ ifdef::VK_NV_fill_rectangle[]
|
|||
feature is not enabled, pname:polygonMode must: be
|
||||
ename:VK_POLYGON_MODE_FILL or ename:VK_POLYGON_MODE_FILL_RECTANGLE_NV
|
||||
* [[VUID-VkPipelineRasterizationStateCreateInfo-polygonMode-01414]]
|
||||
If the +VK_NV_fill_rectangle+ extension is not enabled,
|
||||
If the <<VK_NV_fill_rectangle>> extension is not enabled,
|
||||
pname:polygonMode must: not be ename:VK_POLYGON_MODE_FILL_RECTANGLE_NV
|
||||
endif::VK_NV_fill_rectangle[]
|
||||
****
|
||||
|
|
@ -253,7 +253,7 @@ include::../api/structs/VkPipelineRasterizationStateRasterizationOrderAMD.txt[]
|
|||
|
||||
include::../validity/structs/VkPipelineRasterizationStateRasterizationOrderAMD.txt[]
|
||||
|
||||
If the +VK_AMD_rasterization_order+ device extension is not enabled or the
|
||||
If the <<VK_AMD_rasterization_order>> device extension is not enabled or the
|
||||
application does not request a particular rasterization order through
|
||||
specifying a sname:VkPipelineRasterizationStateRasterizationOrderAMD
|
||||
structure then the rasterization order used by the graphics pipeline
|
||||
|
|
@ -400,7 +400,7 @@ the same color value the fragment mask may: have two samples referring to
|
|||
the same color fragment.
|
||||
The number of color fragments is determined by the pname:samples member of
|
||||
the slink:VkImageCreateInfo structure used to create the image.
|
||||
The +VK_AMD_shader_fragment_mask+ device extension provides shader
|
||||
The <<VK_AMD_shader_fragment_mask>> device extension provides shader
|
||||
instructions enabling the application to get direct access to the fragment
|
||||
mask and the individual color fragment values.
|
||||
|
||||
|
|
@ -973,7 +973,7 @@ outputs are taken from the corresponding input value of the
|
|||
primitive.
|
||||
|
||||
ifdef::VK_AMD_shader_explicit_vertex_parameter[]
|
||||
When the +VK_AMD_shader_explicit_vertex_parameter+ device extension is
|
||||
When the <<VK_AMD_shader_explicit_vertex_parameter>> device extension is
|
||||
enabled the code:CustomInterpAMD <<shaders-interpolation-decorations,
|
||||
interpolation decoration>> can: also be used with fragment shader inputs
|
||||
which indicate that the decorated inputs can: only be accessed by the
|
||||
|
|
|
|||
|
|
@ -317,7 +317,7 @@ The only supported per-view attributes are position and viewport mask, and
|
|||
per-view position and viewport masks are written to output array variables
|
||||
decorated with code:PositionPerViewNV and code:ViewportMaskPerViewNV,
|
||||
respectively.
|
||||
If +VK_NV_viewport_array2+ is not supported and enabled,
|
||||
If <<VK_NV_viewport_array2>> is not supported and enabled,
|
||||
code:ViewportMaskPerViewNV must: not be used.
|
||||
Values written to elements of code:PositionPerViewNV and
|
||||
code:ViewportMaskPerViewNV must: not depend on the code:ViewIndex.
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ ifdef::VK_EXT_sampler_filter_minmax[]
|
|||
endif::VK_EXT_sampler_filter_minmax[]
|
||||
endif::VK_KHR_sampler_ycbcr_conversion[]
|
||||
* [[VUID-VkSamplerCreateInfo-addressModeU-01079]]
|
||||
If the +VK_KHR_sampler_mirror_clamp_to_edge+ extension is not enabled,
|
||||
If the <<VK_KHR_sampler_mirror_clamp_to_edge>> extension is not enabled,
|
||||
pname:addressModeU, pname:addressModeV and pname:addressModeW must: not
|
||||
be ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
|
||||
* [[VUID-VkSamplerCreateInfo-compareEnable-01080]]
|
||||
|
|
@ -344,8 +344,8 @@ include::../api/enums/VkSamplerAddressMode.txt[]
|
|||
to border wrap mode will be used.
|
||||
* ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE specifies that the
|
||||
mirror clamp to edge wrap mode will be used.
|
||||
This is only valid if the +VK_KHR_mirror_clamp_to_edge+ extension is
|
||||
enabled.
|
||||
This is only valid if the <<VK_KHR_sampler_mirror_clamp_to_edge>>
|
||||
extension is enabled.
|
||||
|
||||
--
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ Pipelines>> and <<pipelines-graphics,Graphics Pipelines>>.
|
|||
ifdef::VK_NV_glsl_shader[]
|
||||
If the shader stage fails to compile ename:VK_ERROR_INVALID_SHADER_NV will
|
||||
be generated and the compile log will be reported back to the application by
|
||||
+VK_EXT_debug_report+ if enabled.
|
||||
<<VK_EXT_debug_report>> if enabled.
|
||||
endif::VK_NV_glsl_shader[]
|
||||
|
||||
include::../validity/protos/vkCreateShaderModule.txt[]
|
||||
|
|
@ -622,7 +622,7 @@ vectors, or any double-precision floating-point type must: be decorated with
|
|||
code:Flat.
|
||||
|
||||
ifdef::VK_AMD_shader_explicit_vertex_parameter[]
|
||||
When the +VK_AMD_shader_explicit_vertex_parameter+ device extension is
|
||||
When the <<VK_AMD_shader_explicit_vertex_parameter>> device extension is
|
||||
enabled inputs can: be also decorated with the code:CustomInterpAMD
|
||||
interpolation decoration, including fragment shader inputs that are signed
|
||||
or unsigned integers, integer vectors, or any double-precision
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ class ExtensionMetaDocOutputGenerator(OutputGenerator):
|
|||
write(' - Requires Vulkan 1.0', file=fp)
|
||||
if requires != None:
|
||||
for dep in requires.split(','):
|
||||
write(' - Requires <<' + dep + ',`' + dep + '`>>', file=fp)
|
||||
write(' - Requires <<' + dep + '>>', file=fp)
|
||||
|
||||
write('*Contact*::', file=fp)
|
||||
write(' - ' + contact, file=fp)
|
||||
|
|
|
|||
Loading…
Reference in New Issue