14 changes: 11 additions & 3 deletions chapters/video_decode_h264_extensions.adoc
View file
Expand Up @@ -5,13 +5,21 @@
[[decode-h264]]
== Video Decode of AVC (ITU-T H.264)

This extension adds H.264 codec specific structures needed for decode
session to execute decode jobs which include H.264 sequence header, picture
parameter header and quantization matrix etc.
The `apiext:VK_EXT_video_decode_h264` extension adds H.264 codec specific
structures needed for decode session to execute decode jobs which include
H.264 sequence header, picture parameter header and quantization matrix etc.
Unless otherwise noted, all references to the H.264 specification are to the
2010 edition published by the ITU-T, dated March 2010.
This specification is available at https://www.itu.int/rec/T-REC-H.264.

[NOTE]
.Note
====
Refer to the <<preamble, Preamble>> for information on how the Khronos
Intellectual Property Rights Policy relates to normative references to
external materials not created by Khronos.
====


=== H.264 decode profile

Expand Down
14 changes: 11 additions & 3 deletions chapters/video_decode_h265_extensions.adoc
View file
Expand Up @@ -5,13 +5,21 @@
[[decode-h265]]
== Video Decode of HEVC (ITU-T H.265)

This extension adds H.265 codec specific structures needed for decode
session to execute decode jobs which include H.265 sequence header, picture
parameter header and quantization matrix etc.
The `apiext:VK_EXT_video_decode_h265` extension adds H.265 codec specific
structures needed for decode session to execute decode jobs which include
H.265 sequence header, picture parameter header and quantization matrix etc.
Unless otherwise noted, all references to the H.265 specification are to the
2013 edition published by the ITU-T, dated April 2013.
This specification is available at https://www.itu.int/rec/T-REC-H.265.

[NOTE]
.Note
====
Refer to the <<preamble, Preamble>> for information on how the Khronos
Intellectual Property Rights Policy relates to normative references to
external materials not created by Khronos.
====


=== H.265 decode profile

Expand Down
12 changes: 10 additions & 2 deletions chapters/video_encode_h264_extensions.adoc
View file
Expand Up @@ -5,12 +5,20 @@
[[encode-h264]]
== Encode H.264

This extension adds H.264 codec specific structures/types needed to support
H.264 encoding.
The `apiext:VK_EXT_video_encode_h264` extension adds H.264 codec specific
structures/types needed to support H.264 encoding.
Unless otherwise noted, all references to the H.264 specification are to the
2010 edition published by the ITU-T, dated March 2010.
This specification is available at https://www.itu.int/rec/T-REC-H.264.

[NOTE]
.Note
====
Refer to the <<preamble, Preamble>> for information on how the Khronos
Intellectual Property Rights Policy relates to normative references to
external materials not created by Khronos.
====


=== H.264 encode profile

Expand Down
12 changes: 10 additions & 2 deletions chapters/video_encode_h265_extensions.adoc
View file
Expand Up @@ -5,12 +5,20 @@
[[encode-h265]]
== Encode H.265

This extension adds H.265 codec-specific structures/types needed to support
H.265 video encoding.
The `apiext:VK_EXT_video_encode_h265` extension adds H.265 codec-specific
structures/types needed to support H.265 video encoding.
Unless otherwise noted, all references to the H.265 specification are to the
2013 edition published by the ITU-T, dated April 2013.
This specification is available at https://www.itu.int/rec/T-REC-H.265.

[NOTE]
.Note
====
Refer to the <<preamble, Preamble>> for information on how the Khronos
Intellectual Property Rights Policy relates to normative references to
external materials not created by Khronos.
====


=== H.265 encode profile

Expand Down
102 changes: 55 additions & 47 deletions chapters/video_extensions.adoc
View file
Expand Up @@ -865,9 +865,9 @@ extension.
ifdef::VK_KHR_video_decode_queue[]
[open,refpage='VkVideoDecodeUsageInfoKHR',desc='Structure specifying video decode usage information',type='structs']
--
Additional information about the video decode use case can: be provided
by adding a sname:VkVideoDecodeUsageInfoKHR structure to the pname:pNext
chain of slink:VkVideoProfileInfoKHR.
Additional information about the video decode use case can: be provided by
adding a sname:VkVideoDecodeUsageInfoKHR structure to the pname:pNext chain
of slink:VkVideoProfileInfoKHR.

The sname:VkVideoDecodeUsageInfoKHR structure is defined as:

Expand All @@ -876,8 +876,9 @@ include::{generated}/api/structs/VkVideoDecodeUsageInfoKHR.adoc[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to a structure extending this
structure.
* pname:videoUsageHints is a bitmask of elink:VkVideoDecodeUsageFlagBitsKHR
specifying hints about the intended use of the video decode profile.
* pname:videoUsageHints is a bitmask of
elink:VkVideoDecodeUsageFlagBitsKHR specifying hints about the intended
use of the video decode profile.

include::{generated}/validity/structs/VkVideoDecodeUsageInfoKHR.adoc[]
--
Expand All @@ -893,19 +894,20 @@ include::{generated}/api/enums/VkVideoDecodeUsageFlagBitsKHR.adoc[]
* ename:VK_VIDEO_DECODE_USAGE_TRANSCODING_BIT_KHR specifies that video
decoding is intended to be used in conjunction with video encoding to
transcode a video bitstream with the same and/or different codecs.
* ename:VK_VIDEO_DECODE_USAGE_OFFLINE_BIT_KHR specifies that video decoding
is intended to be used to consume a local video bitstream.
* ename:VK_VIDEO_DECODE_USAGE_OFFLINE_BIT_KHR specifies that video
decoding is intended to be used to consume a local video bitstream.
* ename:VK_VIDEO_DECODE_USAGE_STREAMING_BIT_KHR specifies that video
decoding is intended to be used to consume a video bitstream received
as a continuous flow over network.
decoding is intended to be used to consume a video bitstream received as
a continuous flow over network.

[NOTE]
.Note
====
There are no restrictions on the combination of bits that can: be specified by
the application. However, applications should: use reasonable combinations in
order for the implementation to be able to select the most appropriate mode of
operation for the particular use case.
There are no restrictions on the combination of bits that can: be specified
by the application.
However, applications should: use reasonable combinations in order for the
implementation to be able to select the most appropriate mode of operation
for the particular use case.
====

--
Expand All @@ -914,17 +916,17 @@ operation for the particular use case.
--
include::{generated}/api/flags/VkVideoDecodeUsageFlagsKHR.adoc[]

tlink:VkVideoDecodeUsageFlagsKHR is a bitmask type for setting a mask of zero
or more elink:VkVideoDecodeUsageFlagBitsKHR.
tlink:VkVideoDecodeUsageFlagsKHR is a bitmask type for setting a mask of
zero or more elink:VkVideoDecodeUsageFlagBitsKHR.
--
endif::VK_KHR_video_decode_queue[]

ifdef::VK_KHR_video_encode_queue[]
[open,refpage='VkVideoEncodeUsageInfoKHR',desc='Structure specifying video encode usage information',type='structs']
--
Additional information about the video encode use case can: be provided
by adding a sname:VkVideoEncodeUsageInfoKHR structure to the pname:pNext
chain of slink:VkVideoProfileInfoKHR.
Additional information about the video encode use case can: be provided by
adding a sname:VkVideoEncodeUsageInfoKHR structure to the pname:pNext chain
of slink:VkVideoProfileInfoKHR.

The sname:VkVideoEncodeUsageInfoKHR structure is defined as:

Expand All @@ -933,8 +935,9 @@ include::{generated}/api/structs/VkVideoEncodeUsageInfoKHR.adoc[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to a structure extending this
structure.
* pname:videoUsageHints is a bitmask of elink:VkVideoEncodeUsageFlagBitsKHR
specifying hints about the intended use of the video encode profile.
* pname:videoUsageHints is a bitmask of
elink:VkVideoEncodeUsageFlagBitsKHR specifying hints about the intended
use of the video encode profile.
* pname:videoContentHints is a bitmask of
elink:VkVideoEncodeContentFlagBitsKHR specifying hints about the content
to be encoded using the video encode profile.
Expand Down Expand Up @@ -967,10 +970,11 @@ include::{generated}/api/enums/VkVideoEncodeUsageFlagBitsKHR.adoc[]
[NOTE]
.Note
====
There are no restrictions on the combination of bits that can: be specified by
the application. However, applications should: use reasonable combinations in
order for the implementation to be able to select the most appropriate mode of
operation for the particular use case.
There are no restrictions on the combination of bits that can: be specified
by the application.
However, applications should: use reasonable combinations in order for the
implementation to be able to select the most appropriate mode of operation
for the particular use case.
====

--
Expand All @@ -979,8 +983,8 @@ operation for the particular use case.
--
include::{generated}/api/flags/VkVideoEncodeUsageFlagsKHR.adoc[]

tlink:VkVideoEncodeUsageFlagsKHR is a bitmask type for setting a mask of zero
or more elink:VkVideoEncodeUsageFlagBitsKHR.
tlink:VkVideoEncodeUsageFlagsKHR is a bitmask type for setting a mask of
zero or more elink:VkVideoEncodeUsageFlagBitsKHR.
--

[open,refpage='VkVideoEncodeContentFlagBitsKHR',desc='Video encode content flags',type='enums']
Expand All @@ -991,8 +995,8 @@ encoded video content:

include::{generated}/api/enums/VkVideoEncodeContentFlagBitsKHR.adoc[]

* ename:VK_VIDEO_ENCODE_CONTENT_CAMERA_BIT_KHR specifies that video encoding
is intended to be used to encode camera content.
* ename:VK_VIDEO_ENCODE_CONTENT_CAMERA_BIT_KHR specifies that video
encoding is intended to be used to encode camera content.
* ename:VK_VIDEO_ENCODE_CONTENT_DESKTOP_BIT_KHR specifies that video
encoding is intended to be used to encode desktop content.
* ename:VK_VIDEO_ENCODE_CONTENT_RENDERED_BIT_KHR specified that video
Expand All @@ -1001,10 +1005,11 @@ include::{generated}/api/enums/VkVideoEncodeContentFlagBitsKHR.adoc[]
[NOTE]
.Note
====
There are no restrictions on the combination of bits that can: be specified by
the application. However, applications should: use reasonable combinations in
order for the implementation to be able to select the most appropriate mode of
operation for the particular content type.
There are no restrictions on the combination of bits that can: be specified
by the application.
However, applications should: use reasonable combinations in order for the
implementation to be able to select the most appropriate mode of operation
for the particular content type.
====

--
Expand All @@ -1013,8 +1018,8 @@ operation for the particular content type.
--
include::{generated}/api/flags/VkVideoEncodeContentFlagsKHR.adoc[]

tlink:VkVideoEncodeContentFlagsKHR is a bitmask type for setting a mask of zero
or more elink:VkVideoEncodeContentFlagBitsKHR.
tlink:VkVideoEncodeContentFlagsKHR is a bitmask type for setting a mask of
zero or more elink:VkVideoEncodeContentFlagBitsKHR.
--

[open,refpage='VkVideoEncodeTuningModeKHR',desc='Video encode tuning mode',type='enums']
Expand All @@ -1023,23 +1028,26 @@ Possible video encode tuning mode values are as follows:

include::{generated}/api/enums/VkVideoEncodeTuningModeKHR.adoc[]

* ename:VK_VIDEO_ENCODE_TUNING_MODE_DEFAULT_KHR specifies the default tuning
mode.
* ename:VK_VIDEO_ENCODE_TUNING_MODE_DEFAULT_KHR specifies the default
tuning mode.
* ename:VK_VIDEO_ENCODE_TUNING_MODE_HIGH_QUALITY_KHR specifies that video
encoding is tuned for high quality. When using this tuning mode, the
implementation may: compromise the latency of video encoding operations
to improve quality.
encoding is tuned for high quality.
When using this tuning mode, the implementation may: compromise the
latency of video encoding operations to improve quality.
* ename:VK_VIDEO_ENCODE_TUNING_MODE_LOW_LATENCY_KHR specifies that video
encoding is tuned for low latency. When using this tuning mode, the
implementation may: compromise quality to increase the performance and
lower the latency of video encode operations.
encoding is tuned for low latency.
When using this tuning mode, the implementation may: compromise quality
to increase the performance and lower the latency of video encode
operations.
* ename:VK_VIDEO_ENCODE_TUNING_MODE_ULTRA_LOW_LATENCY_KHR specifies that
video encoding is tuned for ultra-low latency. When using this tuning
mode, the implementation may: compromise quality to maximimize the
performance and minimize the latency of video encoding operations.
video encoding is tuned for ultra-low latency.
When using this tuning mode, the implementation may: compromise quality
to maximimize the performance and minimize the latency of video encoding
operations.
* ename:VK_VIDEO_ENCODE_TUNING_MODE_LOSSLESS_KHR specifies that video
encoding is tuned for lossless encoding. When using this tuning mode,
video encode operations produce lossless output.
encoding is tuned for lossless encoding.
When using this tuning mode, video encode operations produce lossless
output.

--
endif::VK_KHR_video_encode_queue[]
Expand Down
3 changes: 3 additions & 0 deletions config/CI/txt-files-allowed
View file
@@ -0,0 +1,3 @@
^\./LICENSES/
^\./node_modules/
^\./git/
106 changes: 62 additions & 44 deletions copyright-spec.adoc
View file
Expand Up @@ -5,64 +5,82 @@ proprietary to Khronos. Except as described by these terms, it or any
components may not be reproduced, republished, distributed, transmitted,
displayed, broadcast or otherwise exploited in any manner without the
express prior written permission of Khronos.

Khronos grants a conditional copyright license to use and reproduce the
unmodified Specification for any purpose, without fee or royalty, EXCEPT no
licenses to any patent, trademark or other intellectual property rights are
granted under these terms.
granted under these terms. Parties desiring to implement the Specification
and make use of Khronos trademarks in relation to that implementation, and
receive reciprocal patent license protection under the Khronos IP Policy
must become Adopters and confirm the implementation as conformant under the
process defined by Khronos for this Specification; see
https://www.khronos.org/adopters.

Khronos makes no, and expressly disclaims any, representations or
warranties, express or implied, regarding this Specification, including,
without limitation: merchantability, fitness for a particular purpose,
non-infringement of any intellectual property, correctness, accuracy,
completeness, timeliness, and reliability.
Under no circumstances will Khronos, or any of its Promoters, Contributors
or Members, or their respective partners, officers, directors, employees,
agents or representatives be liable for any damages, whether direct,
indirect, special or consequential damages for lost revenues, lost profits,
or otherwise, arising from or in connection with these materials.
completeness, timeliness, and reliability. Under no circumstances will
Khronos, or any of its Promoters, Contributors or Members, or their
respective partners, officers, directors, employees, agents or
representatives be liable for any damages, whether direct, indirect, special
or consequential damages for lost revenues, lost profits, or otherwise,
arising from or in connection with these materials.

This Specification has been created under the Khronos Intellectual Property
Rights Policy, which is Attachment A of the Khronos Group Membership
Agreement available at https://www.khronos.org/files/member_agreement.pdf, and which
defines the terms 'Scope', 'Compliant Portion', and 'Necessary Patent Claims'.
Parties desiring to implement the Specification and make use of Khronos trademarks
in relation to that implementation, and receive reciprocal patent license protection
under the Khronos Intellectual Property Rights Policy must become Adopters and
confirm the implementation as conformant under the process defined by Khronos for
this Specification; see https://www.khronos.org/adopters.
Agreement available at https://www.khronos.org/files/member_agreement.pdf.

// "Successor Specification" section

This Specification contains substantially unmodified functionality from, and
is a successor to, Khronos specifications including OpenGL, OpenGL ES and
OpenCL.

// End "Successor Specification" section

// "Normative Wording" section

This Specification contains substantially unmodified functionality from, and is a
successor to, Khronos specifications including OpenGL, OpenGL ES and OpenCL.
The Khronos Intellectual Property Rights defines the terms 'Scope',
'Compliant Portion', and 'Necessary Patent Claims'.

Some parts of this Specification are purely informative and so are EXCLUDED from
the Scope of this Specification. The <<introduction-conventions>> section of the
<<introduction>> defines how these parts of the Specification are identified.

Where this Specification uses <<introduction-technical-terminology,technical
terminology>>, defined in the <<glossary>> or otherwise, that refer to
enabling technologies that are not expressly set forth in this
Specification, those enabling technologies are EXCLUDED from the Scope of
this Specification.
For clarity, enabling technologies not disclosed with particularity in this
Specification (e.g. semiconductor manufacturing technology, hardware
architecture, processor architecture or microarchitecture, memory
architecture, compiler technology, object oriented technology, basic
operating system technology, compression technology, algorithms, and so on)
are NOT to be considered expressly set forth; only those application program
interfaces and data structures disclosed with particularity are included in
the Scope of this Specification.

For purposes of the Khronos Intellectual Property Rights Policy as it relates
to the definition of Necessary Patent Claims, all recommended or optional
features, behaviors and functionality set forth in this Specification, if
implemented, are considered to be included as Compliant Portions.

Where this Specification includes <<introduction-normative-references,
normative references to external documents>>, only the specifically
identified sections of those external documents are INCLUDED in the Scope of
this Specification. If not created by Khronos, those external documents may
contain contributions from non-members of Khronos not covered by the Khronos
Intellectual Property Rights Policy.
terminology>>, defined in the <<glossary, Glossary>> or otherwise, that
refer to enabling technologies that are not expressly set
forth in this Specification, those enabling technologies are EXCLUDED from
the Scope of this Specification. For clarity, enabling technologies not
disclosed with particularity in this Specification (e.g. semiconductor
manufacturing technology, hardware architecture, processor architecture or
microarchitecture, memory architecture, compiler technology, object oriented
technology, basic operating system technology, compression technology,
algorithms, and so on) are NOT to be considered expressly set forth; only
those application program interfaces and data structures disclosed with
particularity are included in the Scope of this Specification.

For purposes of the Khronos Intellectual Property Rights Policy as it
relates to the definition of Necessary Patent Claims, all recommended or
optional features, behaviors and functionality set forth in this
Specification, if implemented, are considered to be included as Compliant
Portions.

// End "Normative Wording" section

// "External References" section

Where this Specification identifies specific sections of external
references, only those specifically identified sections define
<<introduction-normative-references, normative>>
functionality. The Khronos Intellectual Property Rights Policy excludes
external references to materials and associated enabling technology not
created by Khronos from the Scope of this specification, and any licenses
that may be required to implement such referenced materials and associated
technologies must be obtained separately and may involve royalty payments.

// End "External References" section

ifndef::ratified_core_spec[]
This document contains extensions which are not ratified by Khronos, and as
Expand All @@ -75,9 +93,9 @@ https://registry.khronos.org/vulkan/specs/1.2-khr-extensions/html/vkspec.html
(core with KHR extensions).
endif::ratified_core_spec[]

Vulkan and Khronos are registered trademarks of The Khronos Group Inc.
ASTC is a trademark of ARM Holdings PLC; OpenCL is a trademark of Apple
Inc.; and OpenGL and OpenGL ES are registered trademarks of Hewlett Packard
Enterprise, all used under license by Khronos. All other product names,
Khronos and Vulkan are registered trademarks of The Khronos Group Inc.
OpenCL is a trademark of Apple Inc.; and OpenGL and OpenGL ES are registered
trademarks of Hewlett Packard Enterprise, all used under license by Khronos.
ASTC is a trademark of ARM Holdings PLC. All other product names,
trademarks, and/or company names are used solely for identification and
belong to their respective owners.
15 changes: 12 additions & 3 deletions makeSpec
View file
Expand Up @@ -124,14 +124,23 @@ if __name__ == '__main__':
args = [ 'make', 'GENERATED=' + results.genpath ]

if results.clean:
execute(args + ['clean'], results)
# If OUTDIR is set on the command line, pass it to the 'clean'
# target so it is cleaned as well.
cleanopts = ['clean']
for opt in options:
if opt[:7] == 'OUTDIR=':
cleanopts.append(opt)
try:
execute(args + cleanopts, results)
except:
sys.exit(1)

args.append(versions)

# The actual target
if len(exts) > 0:
args.append('EXTENSIONS={}'.format(' '.join(sorted(exts))))
args.append('APITITLE={}'.format(title))
args.append(f'EXTENSIONS={" ".join(sorted(exts))}')
args.append(f'APITITLE={title}')
args += options

try:
Expand Down
2 changes: 1 addition & 1 deletion proposals/Roadmap.adoc
View file
Expand Up @@ -4,7 +4,7 @@

# Vulkan Roadmap
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document proposes the development of a shared public roadmap for features across mid-to-high-end devices in smartphone, tablet, laptop, console, and desktop markets.
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_AMD_shader_early_and_late_fragment_tests.adoc
View file
Expand Up @@ -4,7 +4,7 @@

# VK_AMD_shader_early_and_late_fragment_tests
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document describes a proposal for a new SPIR-V execution mode that allows fragment shaders to be discarded by early fragment operations, even if they contain writes to storage resources or other side effects.
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_EXT_attachment_feedback_loop_layout.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_EXT_attachment_feedback_loop_layout
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document details API design ideas for the `VK_EXT_attachment_feedback_loop_layout` extension,
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_EXT_graphics_pipeline_library.adoc
View file
Expand Up @@ -4,7 +4,7 @@

# VK_EXT_graphics_pipeline_library
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document outlines a proposal to allow partial compilation of portions
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_EXT_image_2d_array_of_3d.adoc
View file
Expand Up @@ -4,7 +4,7 @@

# VK_EXT_image_2d_array_of_3d
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document proposes adding support for creating 2D views of 3D images.
Expand Down
4 changes: 2 additions & 2 deletions proposals/VK_EXT_image_compression_control.adoc
View file
Expand Up @@ -2,9 +2,9 @@
//
// SPDX-License-Identifier: CC-BY-4.0

= Proposal Template
= VK_EXT_image_compression_control
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document proposes adding support for fixed-rate, or 'lossy', image compression.
Expand Down
560 changes: 560 additions & 0 deletions proposals/VK_EXT_mesh_shader.adoc
View file

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion proposals/VK_EXT_metal_objects.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_EXT_metal_objects
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document details API design ideas for the `VK_EXT_metal_objects` extension,
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_EXT_multisampled_render_to_single_sampled.adoc
View file
Expand Up @@ -4,7 +4,7 @@

# VK_EXT_multisampled_render_to_single_sampled
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document identifies difficulties with efficient multisampled rendering on
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_EXT_non_seamless_cube_map.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_EXT_non_seamless_cube_map
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

== Problem Statement
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_EXT_primitives_generated_query.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_EXT_primitives_generated_query
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This proposal regards layering OpenGL over Vulkan, and provides a convenience
Expand Down
6 changes: 3 additions & 3 deletions proposals/VK_EXT_rasterization_order_attachment_access.adoc
View file
Expand Up @@ -2,9 +2,9 @@
//
// SPDX-License-Identifier: CC-BY-4.0

= Proposal Template
= VK_EXT_rasterization_order_attachment_access
:toc: left
:refpage: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/
:refpage: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This proposal extends the mechanism of input attachments to allow access to framebuffer attachments that are used both as input and as
Expand All @@ -16,7 +16,7 @@ Renderpasses, and specifically subpass self-dependencies enable much of the same
fetch and pixel local storage extensions did for OpenGL ES.
But certain techniques such as programmable blending are awkward or impractical to implement with these alone, in part because a self-dependency
is required every time a fragment will read a value at a given sample coordinate.
For these use-cases, a mechanisms that more closely matches framebuffer fetch is useful.
For these use-cases, a mechanisms that more closely matches framebuffer fetch is useful.

== Solution Space

Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_GOOGLE_surfaceless_query.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_GOOGLE_surfaceless_query
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This proposal regards layering OpenGL over Vulkan, and addresses a discrepancy
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_HUAWEI_invocation_mask.adoc
View file
Expand Up @@ -5,7 +5,7 @@

= VK_HUAWEI_invocation_mask
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/



Expand Down
4 changes: 2 additions & 2 deletions proposals/VK_KHR_dynamic_rendering.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_KHR_dynamic_rendering
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document details API design ideas for the VK_KHR_dynamic_rendering extension, which adds a more dynamic and flexible way to use draw commands, as a straightforward replacement for single pass render passes.
Expand Down Expand Up @@ -275,7 +275,7 @@ If either `depthAttachmentFormat` or `stencilAttachmentFormat` are not `VK_FORMA

The value of `viewMask` must match the value of the `viewMask` member of `VkRenderingInfoKHR`.

===== Multiview Per-View Attributes
==== Multiview Per-View Attributes

If link:{refpage}VK_NVX_multiview_per_view_attributes.html[VK_NVX_multiview_per_view_attributes] is enabled, the multiview per-view attributes can be specified by including the `VkMultiviewPerViewAttributesInfoNVX` structure in the same `pNext` chain.

Expand Down
10 changes: 5 additions & 5 deletions proposals/VK_KHR_fragment_shader_barycentric.adoc
View file
Expand Up @@ -2,9 +2,9 @@
//
// SPDX-License-Identifier: CC-BY-4.0

= Proposal Template
= VK_KHR_fragment_shader_barycentric
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document details the VK_KHR_fragment_shader_barcentric extension, which adds a cross-vendor way to access barycentric coordinates in a fragment shader.
Expand Down Expand Up @@ -55,8 +55,8 @@ Vertices are numbered as follows:

[cols="10,10,10,10",options="header",width = "80%"]
|====
| Primitive Topology | Vertex 0 | Vertex 1 | Vertex 2
| `VK_PRIMITIVE_TOPOLOGY_POINT_LIST` | i | i | i
| Primitive Topology | Vertex 0 | Vertex 1 | Vertex 2
| `VK_PRIMITIVE_TOPOLOGY_POINT_LIST` | i | i | i
| `VK_PRIMITIVE_TOPOLOGY_LINE_LIST` | 2i | 2i+1 | 2i+1
| `VK_PRIMITIVE_TOPOLOGY_LINE_STRIP` | i | i+1 | i+1
| `VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST` | 3i | 3i+1 | 3i+2
Expand All @@ -74,7 +74,7 @@ When the provoking vertex mode is `VK_PROVOKING_VERTEX_MODE_LAST_VERTEX_EXT`, th

[cols="10,10,10,10",options="header",width = "80%"]
|====
| Primitive Topology | Vertex 0 | Vertex 1 | Vertex 2
| Primitive Topology | Vertex 0 | Vertex 1 | Vertex 2
| VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP (odd, and `triStripVertexOrderIndependentOfProvokingVertex` is `VK_FALSE`) | i+1 | i | i+2
| VK_PRIMITIVE_TOPOLOGY_TRIANGLE_FAN | 0 | i+1 | i+2
| VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY (odd) | 2i+2 | 2i | 2i+4
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_KHR_fragment_shading_rate.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_KHR_fragment_shading_rate
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This extension adds the ability to change the rate at which fragments are shaded. Rather than the usual single fragment invocation for each pixel covered by a primitive, multiple pixels can be shaded by a single fragment shader invocation.
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_KHR_shader_integer_dot_product.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_KHR_shader_integer_dot_product
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document proposes adding support for shader integer dot product instructions.
Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_QCOM_image_processing.adoc
View file
Expand Up @@ -4,7 +4,7 @@

# VK_QCOM_image_processing
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:


Expand Down
2 changes: 1 addition & 1 deletion proposals/VK_QCOM_tile_properties.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= VK_QCOM_tile_properties
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document details API design ideas for the VK_QCOM_tile_properties extension, which allows application to query the tile properties. This extension supports both renderpasses and dynamic rendering.
Expand Down
2 changes: 1 addition & 1 deletion proposals/template.adoc
View file
Expand Up @@ -4,7 +4,7 @@

= Proposal Template
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.2-extensions/man/html/
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

.How to use this document
Expand Down
16 changes: 13 additions & 3 deletions registry.adoc
View file
Expand Up @@ -19,6 +19,9 @@ Jon Leech
// Various special / math symbols. This is easier to edit with than Unicode.
include::{config}/attribs.adoc[]

// Core versions and extensions to enable
include::{generated}/specattribs.adoc[]

:leveloffset: 1

<<<<
Expand Down Expand Up @@ -1533,9 +1536,13 @@ tag:feature tags already define a specific API.
These attributes are allowed only for a tag:require tag.

* attr:extension - optional, and only for tag:require tags.
String containing an API extension name.
Interfaces in the tag are only required if the string matches the
attr:name of an tag:extension tag, and that extension is enabled.
String containing one or more API extension names separated by `,` or
`+`.
Interfaces in the tag are only required if enabled extensions satisfy
the logical expression in the string, where `,` is interpreted as a
logical OR and '+' as a logical AND.
Each extension name in the string must match the attr:name of a
tag:extension tag.
* attr:feature - optional, and only for tag:require tags.
String containing an API feature name.
Interfaces in the tag are only required if the string matches the
Expand Down Expand Up @@ -2864,6 +2871,9 @@ Changes to the `.xml` files and Python scripts are logged in Github history.
[[changelog]]
= Change Log

* 2022-08-12 - update tag:requires attr:extension syntax to support
logical OR and AND constructs for multiple extensions (internal issue
2922).
* 2022-07-11 - Add attr:videocoding attribute to <<tag-command,tag:command>>
tags to indicate whether a command buffer command can be recorded inside,
outside, or both inside and outside of a video coding scope.
Expand Down
2 changes: 2 additions & 0 deletions roadmap/Roadmap 2022.adoc
View file
Expand Up @@ -2,6 +2,8 @@
//
// SPDX-License-Identifier: CC-BY-4.0

:times: ×

[[roadmap-2022]]
= Roadmap 2022

Expand Down
25 changes: 21 additions & 4 deletions scripts/docgenerator.py
View file
Expand Up @@ -7,6 +7,7 @@
from pathlib import Path

from generator import GeneratorOptions, OutputGenerator, noneStr, write
from parse_dependency import dependencyLanguage

_ENUM_TABLE_PREFIX = """
[cols=",",options="header",]
Expand Down Expand Up @@ -207,12 +208,28 @@ def genRequirements(self, name, mustBeFound = True):
# To simplify this, sort the (base,dependency) requirements
# and put them in a set to ensure they are unique.
features = set()
# 'dependency' may be a boolean expression of extension names
for (base,dependency) in self.apidict.requiredBy[name]:
if dependency is not None:
l = sorted(
sorted((base, dependency)),
key=orgLevelKey)
features.add(' with '.join(l))
# 'dependency' may be a boolean expression of extension
# names, in which case the sorting will not work well.

# First, convert it from asciidoctor markup to language.
depLanguage = dependencyLanguage(dependency, specmacros=False)

# If they are the same, the dependency is only a
# single extension, and sorting them works.
# Otherwise, skip it.
if depLanguage == dependency:
deps = sorted(
sorted((base, dependency)),
key=orgLevelKey)
depString = ' with '.join(deps)
else:
# An expression with multiple extensions
depString = f'{base} with {depLanguage}'

features.add(depString)
else:
features.add(base)
# Sort the overall dependencies so core versions are first
Expand Down
4 changes: 2 additions & 2 deletions scripts/formatsgenerator.py
View file
Expand Up @@ -116,7 +116,7 @@ def endFile(self):
spirv_image_format_table.append('|code:Unknown|Any')
for vk_format, spirv_format in self.spirv_image_format.items():
spirv_image_format_table.append('|code:{}|ename:{}'.format(spirv_format, vk_format))
self.writeBlock('spirvimageformat.txt', spirv_image_format_table)
self.writeBlock(f'spirvimageformat{self.file_suffix}', spirv_image_format_table)

# Generate Plane Format Compatibility Table
plane_format_table = []
Expand Down Expand Up @@ -144,7 +144,7 @@ def endFile(self):
height_divisor))
if add_condition:
plane_format_table.append('endif::{}[]'.format(format_condition))
self.writeBlock('planeformat.txt', plane_format_table)
self.writeBlock(f'planeformat{self.file_suffix}', plane_format_table)

# Finish processing in superclass
OutputGenerator.endFile(self)
Expand Down
9 changes: 8 additions & 1 deletion scripts/genRef.py
View file
Expand Up @@ -18,6 +18,7 @@
printPageInfo, setLogFile)
from reg import Registry
from generator import GeneratorOptions
from parse_dependency import dependencyNames
from apiconventions import APIConventions


Expand Down Expand Up @@ -171,7 +172,11 @@ def seeAlsoList(apiName, explicitRefs=None, apiAliases=[]):
for (base,dependency) in api.requiredBy[name]:
refs.add(base)
if dependency is not None:
refs.add(dependency)
# 'dependency' may be a boolean expression of extension
# names.
# Extract them for use in cross-references.
for extname in dependencyNames(dependency):
refs.add(extname)

if len(refs) == 0:
return None
Expand Down Expand Up @@ -235,6 +240,8 @@ def refPageShell(pageName, pageDesc, fp, head_content = None, sections=None, tai

s = '{}({})'.format(pageName, man_section)
print('= ' + s,
'',
conventions.extra_refpage_body,
'',
sep='\n', file=fp)
if pageDesc.strip() == '':
Expand Down
4 changes: 2 additions & 2 deletions scripts/genvk.py
View file
Expand Up @@ -550,8 +550,8 @@ def makeGenOpts(args):
# These are not Vulkan extensions, or a part of the Vulkan API at all,
# but are treated in a similar fashion for generation purposes.
#
# Each element of the videoStd[] array is an 'extension' name defining
# an interface, and is also the basis for the generated header file name.
# Each element of the videoStd[] array is an extension name defining an
# interface, and is also the basis for the generated header file name.

videoStd = [
'vulkan_video_codecs_common',
Expand Down
24 changes: 15 additions & 9 deletions scripts/interfacedocgenerator.py
View file
Expand Up @@ -6,6 +6,7 @@

import re
from generator import OutputGenerator, write
from parse_dependency import dependencyLanguage

def interfaceDocSortKey(item):
if item == None:
Expand Down Expand Up @@ -51,17 +52,22 @@ def writeNewInterfaces(self, feature, key, title, markup, fp):

# Loop through required blocks, sorted so they start with "core" features
for required in sorted(dict, key = interfaceDocSortKey):
# 'required' may be a boolean expression of extension
# names.
# Currently this syntax is the same as asciidoc conditional
# syntax, but will eventually become more complex.
if required is not None:
requiredlink = 'apiext:' + required
match = re.search("[A-Z]+_VERSION_([0-9]+)_([0-9]+)",required)
if match is not None:
major = match.group(1)
minor = match.group(2)
version = major + '.' + minor
requiredlink = '<<versions-' + version + ', Version ' + version + '>>'

# Rewrite with spec macros and xrefs applied to names
requiredlink = dependencyLanguage(required, specmacros=True)

# @@ A better approach would be to actually evaluate the
# logical expression at generation time.
# If the extensions required are not in the spec build,
# then do not include these requirements.
# This would support arbitrarily complex expressions,
# unlike asciidoc ifdef syntax.
write('ifdef::' + required + '[]', file=fp)
write('If ' + requiredlink + ' is supported:', file=fp)
write(f'If {requiredlink} is supported:', file=fp)
write('',file=fp)

# Commands are relatively straightforward
Expand Down
209 changes: 209 additions & 0 deletions scripts/parse_dependency.py
View file
@@ -0,0 +1,209 @@
# Copyright 2022 The Khronos Group Inc.
# Copyright 2003-2019 Paul McGuire
# SPDX-License-Identifier: MIT

# apirequirements.py - parse 'depends' / 'extension' expressions in API XML
# Supported expressions at present:
# - extension names
# - '+' as AND connector
# - ',' as OR connector
# - parenthesization for grouping (not used yet)
#

# Based on https://github.com/pyparsing/pyparsing/blob/master/examples/fourFn.py

from pyparsing import (
Literal,
Word,
Group,
Forward,
alphas,
alphanums,
Regex,
ParseException,
CaselessKeyword,
Suppress,
delimitedList,
)
import math
import operator
import re

exprStack = []

def push_first(toks):
# print(f'push_first(toks = {toks}): |exprStack| = {len(exprStack)} exprStack = {exprStack}')

exprStack.append(toks[0])

bnf = None

def dependencyBNF():
"""
boolop :: '+' | ','
extname :: Char(alphas)
atom :: extname | '(' expr ')'
expr :: atom [ boolop atom ]*
"""
global bnf
if not bnf:
ident = Word(alphanums + '_')

and_, or_ = map(Literal, '+,')
lpar, rpar = map(Suppress, '()')
boolop = and_ | or_

expr = Forward()
expr_list = delimitedList(Group(expr))
atom = (
boolop[...]
+ (
(ident).setParseAction(push_first)
| Group(lpar + expr + rpar)
)
)

expr <<= atom + (boolop + atom).setParseAction(push_first)[...]
bnf = expr
return bnf


# map operator symbols to corresponding arithmetic operations
opn = {
'+': operator.and_,
',': operator.or_,
}

# map operator symbols to corresponding words
opname = {
'+': 'and',
',': 'or',
}

def extensionIsSupported(extname):
return True

def evaluate_stack(s):
op, num_args = s.pop(), 0
# print(f'evaluate_stack: op = {op} num_args {num_args}')
if isinstance(op, tuple):
op, num_args = op
if op in '+,':
# note: operands are pushed onto the stack in reverse order
op2 = evaluate_stack(s)
op1 = evaluate_stack(s)
return opn[op](op1, op2)
elif op[0].isalpha():
# print(f'extname {op} => {supported(op)}')
return extensionIsSupported(op)
else:
raise Exception(f'invalid op: {op}')

def evalDependencyLanguage(s, specmacros):
"""Evaluate an expression stack, returning an English equivalent
- s - the stack
- specmacros - if True, prepare the language for spec inclusion"""

op, num_args = s.pop(), 0
# print(f'evalDependencyLanguage: op = {op} num_args {num_args}')
if isinstance(op, tuple):
op, num_args = op
if op in '+,':
# @@ Should parenthesize, not needed yet
rhs = evalDependencyLanguage(s, specmacros)
return evalDependencyLanguage(s, specmacros) + f' {opname[op]} ' + rhs
elif op[0].isalpha():
# This is an extension or feature name
if specmacros:
match = re.search("[A-Z]+_VERSION_([0-9]+)_([0-9]+)", op)
if match is not None:
major = match.group(1)
minor = match.group(2)
version = major + '.' + minor
return f'<<versions-{major}.{minor}, Version {version}>>'
else:
return 'apiext:' + op
else:
return op
else:
raise Exception(f'invalid op: {op}')

def dependencyLanguage(dependency, specmacros = False):
"""Return an API dependency expression translated to natural language.
- dependency - the expression
- specmacros - if True, prepare the language for spec inclusion with
macros and xrefs included"""

global exprStack
exprStack = []
results = dependencyBNF().parseString(dependency, parseAll=True)
# print(f'language(): stack = {exprStack}')
return evalDependencyLanguage(exprStack, specmacros)

def evalDependencyNames(s):
"""Evaluate an expression stack, returning a set of names
- s - the stack"""

op, num_args = s.pop(), 0
# print(f'evalDependencyNames: op = {op} num_args {num_args}')
if isinstance(op, tuple):
op, num_args = op
if op in '+,':
# The operation itself is not evaluated, since all we care about is
# the names
return evalDependencyNames(s) | evalDependencyNames(s)
elif op[0].isalpha():
return { op }
else:
raise Exception(f'invalid op: {op}')

def dependencyNames(dependency):
"""Return a set of the extension and version names in an API dependency
expression
- dependency - the expression"""

global exprStack
exprStack = []
results = dependencyBNF().parseString(dependency, parseAll=True)
# print(f'names(): stack = {exprStack}')
return evalDependencyNames(exprStack)

if __name__ == "__main__":

def test(dependency, expected):
global exprStack
exprStack = []

try:
results = dependencyBNF().parseString(dependency, parseAll=True)
# print('test(): stack =', exprStack)
val = evaluate_stack(exprStack[:])
except ParseException as pe:
print(dependency, "failed parse:", str(pe))
except Exception as e:
print(dependency, "failed eval:", str(e), exprStack)
else:
print(dependency, "failed eval:", str(e), exprStack)
if val == expected:
print(f'{dependency} = {val} {results} => {exprStack}')
else:
print(f'{dependency} !!! {val} != {expected} {results} => {exprStack}')

e = 'VK_VERSION_1_1+(bar,spam)'
# test(e, False)
print(f'{e} -> {dependencyNames(e)}')
print('\n------------\n')
print(f'{e} -> {dependencyLanguage(e, False)}')
print('\n------------\n')
print(f'{e} -> {dependencyLanguage(e, True)}')

# test('true', True)
# test('(True)', True)
# test('false,false', False)
# test('false,true', True)
# test('false+true', False)
# test('VK_foo_bar+true', True)
5 changes: 5 additions & 0 deletions scripts/reg.py
View file
Expand Up @@ -996,6 +996,11 @@ def fillFeatureDictionary(self, interface, featurename, api, profile):

# Determine the required extension or version needed for a require block
# Assumes that only one of these is specified
# 'extension', and therefore 'required_key', may be a boolean
# expression of extension names.
# 'required_key' is used only as a dictionary key at
# present, and passed through to the script generators, so
# they must be prepared to parse that expression.
required_key = require.get('feature')
if required_key is None:
required_key = require.get('extension')
Expand Down
4 changes: 3 additions & 1 deletion scripts/scriptgenerator.py
View file
Expand Up @@ -79,7 +79,9 @@ def addInterfaceMapping(self, api, feature, required):
- api - name of the API
- feature - name of the feature requiring it
- required - None, or an additional feature dependency within
'feature' """
'feature'. The additional dependency is a boolean expression of
one or more extension and/or core version names, which is passed
through to the output script intact."""

# Each entry in self.apimap contains one or more
# ( feature, required ) tuples.
Expand Down
13 changes: 13 additions & 0 deletions scripts/spec_tools/conventions.py
View file
Expand Up @@ -430,3 +430,16 @@ def protectProtoComment(self):
"""Return True if generated #endif should have a comment matching
the protection symbol used in the opening #ifdef/#ifndef."""
return False

@property
def extra_refpage_headers(self):
"""Return any extra headers (preceding the title) for generated
reference pages."""
return ''

@property
def extra_refpage_body(self):
"""Return any extra text (following the title) for generated
reference pages."""
return ''

16 changes: 11 additions & 5 deletions scripts/vkconventions.py
View file
Expand Up @@ -201,11 +201,6 @@ def special_use_section_anchor(self):
section describing extension special uses in detail."""
return 'extendingvulkan-compatibility-specialuse'

@property
def extra_refpage_headers(self):
"""Return any extra text to add to refpage headers."""
return 'include::{config}/attribs.adoc[]'

@property
def extension_index_prefixes(self):
"""Return a list of extension prefixes used to group extension refpages."""
Expand Down Expand Up @@ -269,3 +264,14 @@ def valid_flag_bit(self, bitpos):
cause Vk*FlagBits values with bit 31 set to result in a 64 bit
enumerated type, so disallows such flags."""
return bitpos >= 0 and bitpos < 31

@property
def extra_refpage_headers(self):
"""Return any extra text to add to refpage headers."""
return 'include::{config}/attribs.adoc[]'

@property
def extra_refpage_body(self):
"""Return any extra text (following the title) for generated
reference pages."""
return 'include::{generated}/specattribs.adoc[]'
10 changes: 5 additions & 5 deletions style/extensions.adoc
View file
Expand Up @@ -618,9 +618,9 @@ sed -i -E 's/`?<<(VK_[A-Za-z0-9_]*)>>`?/`apiext:\1`/g' chapters/{*.adoc,*/*.adoc
extension name and place the new files there.
For example, instead of `chapters/VK_KHR_android_surface.adoc`, there is
`chapters/VK_KHR_android_surface/platformCreateSurface_android.adoc` and
`chapters/VK_KHR_android_surface/platformQuerySupport_android.adoc`, both
of which are conditionally included elsewhere in the core specification
files.
`chapters/VK_KHR_android_surface/platformQuerySupport_android.adoc`,
both of which are conditionally included elsewhere in the core
specification files.
* Valid usage statements referring to interactions between structures in a
pname:pNext chain must be described in the parent structure's language,
as specified <<extensions-interactions-parent, in more detail below>>.
Expand Down Expand Up @@ -732,8 +732,8 @@ Group.
changes to existing language, to new commands and structures, to adding
entire new chapters.
New chapters must be defined in separate files under the `chapters/`
directory, and included at an appropriate point in `vkspec.adoc` or other
specification source files.
directory, and included at an appropriate point in `vkspec.adoc` or
other specification source files.
Other changes and additions are included inline in existing chapters.
* All changes that are specific to the new version must be protected by
the asciidoctor conditional (e.g. the version name).
Expand Down
6 changes: 3 additions & 3 deletions style/writing.adoc
View file
Expand Up @@ -1078,9 +1078,9 @@ was inserted by a script, not the original author.
If the same set of valid usage statements are going to be common to multiple
commands or structures, these should be extracted into a separate file under
`chapters/commonvalidity/`.
The file name should be short but to the point (e.g. `draw_common.adoc`), and
then the file can be included in the relevant API features using standard
include syntax:
The file name should be short but to the point (e.g. `draw_common.adoc`),
and then the file can be included in the relevant API features using
standard include syntax:
[source,asciidoc,subs=attributes+]
~~~~
Expand Down
3 changes: 3 additions & 0 deletions styleguide.adoc
View file
Expand Up @@ -19,6 +19,9 @@ Jon Leech, Tobias Hector
// Various special / math symbols. This is easier to edit with than Unicode.
include::{config}/attribs.adoc[]

// Core versions and extensions to enable
include::{generated}/specattribs.adoc[]

// Where the current Asciidoctor documentation is found.
:docguide: https://docs.asciidoctor.org/asciidoc/latest

Expand Down
7 changes: 5 additions & 2 deletions vkspec.adoc
View file
Expand Up @@ -18,6 +18,9 @@ The Khronos{regtitle} Vulkan Working Group
// Various special / math symbols. This is easier to edit with than Unicode.
include::config/attribs.adoc[]

// Core versions and extensions to enable
include::{generated}/specattribs.adoc[]

// Table of contents is inserted here
toc::[]

Expand Down Expand Up @@ -91,9 +94,9 @@ include::chapters/tessellation.adoc[]

include::chapters/geometry.adoc[]

ifdef::VK_NV_mesh_shader[]
ifdef::VK_NV_mesh_shader,VK_EXT_mesh_shader[]
include::chapters/VK_NV_mesh_shader/mesh.adoc[]
endif::VK_NV_mesh_shader[]
endif::VK_NV_mesh_shader,VK_EXT_mesh_shader[]

include::chapters/vertexpostproc.adoc[]

Expand Down
172 changes: 157 additions & 15 deletions xml/vk.xml
View file

Large diffs are not rendered by default.