Skip to content

Commit

Permalink
Change log for September 23, 2016 Vulkan 1.0.28 spec update:
Browse files Browse the repository at this point in the history
  * Bump API patch number and header version number to 28 for this update.

Github Issues:

  * Minor spelling and typography cleanup, add definitions of
    ename:VK_FALSE and ename:VK_TRUE as just what their names say
    (public issues 220, 318, 325, 365; internal issues 451, 496)
  * Clarify that the pname:maxDescriptorSet limits in the
    <<features-limits-required,Required Limits>> table are n *
    maxPerStage limit (where n=number of supported stages) (public issue
    254).
  * Minor cleanup to <<boilerplate-platform-macros,Platform-Specific
    Macro Definitions>> appendix (public issue 314).
  * Add valid usage statement to slink:VkPipelineLayoutCreateInfo
    disallowing multiple push constant ranges for the same shader stage
    (public issue 340).
  * Clarify the elink:VkSharingMode description of what executing the
    "same" barriers means in case of ownership transfer (public issue
    347).
  * Rename copyright.txt and add COPYING.md to try and reduce confusion
    about applicable copyrights (public issue 350).
  * Extend the table in the <<boilerplate-wsi-header, Window System-Specific
    Header Control>> section to describe the external headers included when
    each etext:VK_USE_PLATFORM_* macro is defined (public issue 376).

Internal Issues:

  * Add "Revision History" to the PDF outputs following the table of
    contents, to match HTML outputs (internal issue 43).
  * Clarified that flink:vkMapMemory may fail due to virtual address
    space limitations (internal issue 346).
  * Add +refBody+ comment markup for ref page autoextraction when required
    (internal issue 400).
  * Document proper use of "mipmap" and "mip" in the style guide API
    naming rules, matching the spelling rules (internal issue 471).
  * Tweak the <<extensions,Layers and Extensions>> appendix to note that
    the Specification may be built with arbitrary combinations of
    extensions (internal issue 483).
  * Remove incorrect statement allowing
    slink:VkClearAttachment::pname:colorAttachment to be >=
    slink:VkSubpassDescription::pname:colorAttachmentCount (internal
    issue 488).
  * The <<features-limits-viewportboundsrange,viewportBoundsRange>> is
    expressed in terms of the pname:maxViewportDimensions but this is
    actually two values. Clarify that it's based on the larger of the two
    (if they differ) (internal issue 499).

Other Issues:

  * Reflowed text of the entire spec using the 'reflow' Makefile gater,
    to (hopefully) reduce future internal git churn as edits are made
    and extensions added in return for one-time pain. This has no
    perceptible change on the spec outputs but considerable changes on
    the asciidoc source (internal issue 367).
  • Loading branch information
oddhack committed Sep 24, 2016
1 parent ef053e7 commit 95dd2f3
Show file tree
Hide file tree
Showing 117 changed files with 12,169 additions and 10,491 deletions.
32 changes: 32 additions & 0 deletions COPYING.md
@@ -0,0 +1,32 @@
The files in, and generated output documents from this Vulkan-Docs
project are under a mix of copyright and license statements. Refer to
the individual files for specific information. As a general
guideline:

* The Vulkan Specification asciidoc sources and generated output
documents are under a proprietary Khronos license. See
https://www.khronos.org/registry/speccopyright.html
* The Vulkan headers, spec build tools, and spec and registry
configuration files are for the most part under the Apache 2 license.
Some older files under BSD-like licenses which may eventually be
updated to Apache 2 as we have time.
* There may be some configuration files customized from material shipped
with the asciidoc and dblatex distributions. Such files continue under
their original copyrights.
* Documentation which we expect to be redistributed in different
formats, such as the reference pages generated from the Specification
source, are under a Creative Commons Attribution 4.0 license.
* Some generated, transient files produced during the course of building
the specification, headers, or other targets may not have copyrights.
These are typically very short asciidoc fragments describing parts of
the Vulkan API, and are incorporated by reference into specification
or reference page builds.
* If something is missing a copyright statement and that poses an
*actual problem* for whatever you're doing, file an issue on GitHub
and we'll eventually correct it in some fashion.

Working with the different Khronos member company IP lawyers to make
license changes is a very slow process constrained by the Khronos Member
Agreement and IP Policy as well as by individual company concerns about
their IP. Do not expect rapid changes in anything having to to with
copyrights and licensing.
54 changes: 54 additions & 0 deletions ChangeLog.txt
Expand Up @@ -1340,3 +1340,57 @@ Other Issues:
slink:VkSurfaceCapabilitiesKHR::pname:maxImageCount.
* Added +VK_EXT_validation_flags+ extension for validation flag mechanism.
* Fix an <<credits,author credit>> to include their current employer.

-----------------------------------------------------

Change log for September 23, 2016 Vulkan 1.0.28 spec update:

* Bump API patch number and header version number to 28 for this update.

Github Issues:

* Minor spelling and typography cleanup, add definitions of
ename:VK_FALSE and ename:VK_TRUE as just what their names say
(public issues 220, 318, 325, 365; internal issues 451, 496)
* Clarify that the pname:maxDescriptorSet limits in the
<<features-limits-required,Required Limits>> table are n *
maxPerStage limit (where n=number of supported stages) (public issue
254).
* Minor cleanup to <<boilerplate-platform-macros,Platform-Specific
Macro Definitions>> appendix (public issue 314).
* Add valid usage statement to slink:VkPipelineLayoutCreateInfo
disallowing multiple push constant ranges for the same shader stage
(public issue 340).
* Clarify the elink:VkSharingMode description of what executing the
"same" barriers means in case of ownership transfer (public issue
347).
* Rename copyright.txt and add COPYING.md to try and reduce confusion
about applicable copyrights (public issue 350).
* Extend the table in the <<boilerplate-wsi-header, Window System-Specific
Header Control>> section to describe the external headers included when
each etext:VK_USE_PLATFORM_* macro is defined (public issue 376).

Internal Issues:

* Add "Revision History" to the PDF outputs following the table of
contents, to match HTML outputs (internal issue 43).
* Clarified that flink:vkMapMemory may fail due to virtual address
space limitations (internal issue 346).
* Add +refBody+ comment markup for ref page autoextraction when required
(internal issue 400).
* Document proper use of "mipmap" and "mip" in the style guide API
naming rules, matching the spelling rules (internal issue 471).
* Tweak the <<extensions,Layers and Extensions>> appendix to note that
the Specification may be built with arbitrary combinations of
extensions (internal issue 483).
* Remove incorrect statement allowing
slink:VkClearAttachment::pname:colorAttachment to be >=
slink:VkSubpassDescription::pname:colorAttachmentCount (internal
issue 488).
* The <<features-limits-viewportboundsrange,viewportBoundsRange>> is
expressed in terms of the pname:maxViewportDimensions but this is
actually two values. Clarify that it's based on the larger of the two
(if they differ) (internal issue 499).

Other Issues:

4 changes: 2 additions & 2 deletions doc/specs/vulkan/Makefile
Expand Up @@ -160,7 +160,7 @@ GENDEPENDS = api/timeMarker validity/timeMarker hostsynctable/timeMarker
COMMONDOCS = $(CHAPTERS) $(GENINCLUDE) $(GENDEPENDS)
# A generated included file containing the spec version, date, and git commit
SPECVERSION = specversion.txt
SPECREVISION = 1.0.27
SPECREVISION = 1.0.28
SPECREMARK =

# Spec targets
Expand Down Expand Up @@ -308,7 +308,7 @@ MACROSOURCES = $(wildcard $(MANDIR)/VK_*[A-Z][A-Z].txt)
VENSOURCES = $(filter-out $(KHRSOURCES) $(MACROSOURCES),$(wildcard $(MANDIR)/*[A-Z][A-Z].txt))
CORESOURCES = $(filter-out $(KHRSOURCES) $(VENSOURCES) $(MANDIR)/vkman.css,$(wildcard $(MANDIR)/[Vv][Kk]*.txt $(MANDIR)/PFN*.txt))
MANSOURCES = $(CORESOURCES)
MANCOPYRIGHT = $(MANDIR)/khronoscopyright.txt $(MANDIR)/footer.txt
MANCOPYRIGHT = $(MANDIR)/copyright-ccby.txt $(MANDIR)/footer.txt

# Automatic generation of ref pages. Needs to have a proper dependency
# causing the man page sources to be generated by running genRef (once),
Expand Down
13 changes: 8 additions & 5 deletions doc/specs/vulkan/appendices/VK_AMD_draw_indirect_count.txt
Expand Up @@ -2,7 +2,7 @@
== VK_AMD_draw_indirect_count

*Name String*::
VK_AMD_draw_indirect_count
+VK_AMD_draw_indirect_count+
*Extension Type*::
Device extension
*Registered Extension Number*::
Expand All @@ -16,17 +16,20 @@
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
*Contributors*::
- Matthaeus G. Chajdas, AMD
- Matthaeus G.
Chajdas, AMD
- Derrick Owens, AMD
- Graham Sellers, AMD
- Daniel Rakos, AMD
- Dominik Witczak, AMD
*Contacts*::
- Matthaeus G. Chajdas, AMD (matthaeus.chajdas@amd.com)
- Matthaeus G.
Chajdas, AMD (matthaeus.chajdas@amd.com)

This extension allows an application to source the number of draw calls for
indirect draw calls from a buffer. This enables applications to generate arbitrary
amounts of draw commands and execute them without host intervention.
indirect draw calls from a buffer.
This enables applications to generate arbitrary amounts of draw commands and
execute them without host intervention.

=== New Functions

Expand Down
4 changes: 2 additions & 2 deletions doc/specs/vulkan/appendices/VK_AMD_gcn_shader.txt
Expand Up @@ -2,7 +2,7 @@
== VK_AMD_gcn_shader

*Name String*::
VK_AMD_gcn_shader
+VK_AMD_gcn_shader+
*Extension Type*::
Device extension
*Registered Extension Number*::
Expand All @@ -25,7 +25,7 @@

This extension adds support for the following SPIR-V extension in {apiname}:

* SPV_AMD_gcn_shader
* +SPV_AMD_gcn_shader+

=== Version History

Expand Down
36 changes: 36 additions & 0 deletions doc/specs/vulkan/appendices/VK_AMD_gpu_shader_half_float.txt
@@ -0,0 +1,36 @@
[[VK_AMD_gpu_shader_half_float]]
== VK_AMD_gpu_shader_half_float

*Name String*::
+VK_AMD_gpu_shader_half_float+
*Extension Type*::
Device extension
*Registered Extension Number*::
37
*Last Modified Date*::
2016-09-21
*Revision*::
1
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0.27 of the Vulkan API.
*Contributors*::
- Daniel Rakos, AMD
- Dominik Witczak, AMD
- Donglin Wei, AMD
- Graham Sellers, AMD
- Qun Lin, AMD
- Rex Xu, AMD

*Contacts*::
- Dominik Witczak, AMD (Dominik.Witczak@amd.com)

This extension adds support for the following SPIR-V extension in {apiname}:

* +SPV_AMD_gpu_shader_half_float+

=== Version History

* Revision 1, 2019-09-21 (Dominik Witczak)
- Initial draft
11 changes: 7 additions & 4 deletions doc/specs/vulkan/appendices/VK_AMD_negative_viewport_height.txt
Expand Up @@ -2,7 +2,7 @@
== VK_AMD_negative_viewport_height

*Name String*::
VK_AMD_negative_viewport_height
+VK_AMD_negative_viewport_height+
*Extension Type*::
Device extension
*Registered Extension Number*::
Expand All @@ -16,13 +16,16 @@
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
*Contributors*::
- Matthaeus G. Chajdas, AMD
- Matthaeus G.
Chajdas, AMD
- Graham Sellers, AMD
- Baldur Karlsson
*Contacts*::
- Matthaeus G. Chajdas, AMD (matthaeus.chajdas@amd.com)
- Matthaeus G.
Chajdas, AMD (matthaeus.chajdas@amd.com)

This extension allows an application to specify a negative viewport height. The result is that the viewport transformation will flip along the y-axis.
This extension allows an application to specify a negative viewport height.
The result is that the viewport transformation will flip along the y-axis.

* Revision 1, 2016-09-02 (Matthaeus Chajdas)
- Initial draft
43 changes: 24 additions & 19 deletions doc/specs/vulkan/appendices/VK_AMD_rasterization_order.txt
Expand Up @@ -2,7 +2,7 @@
== VK_AMD_rasterization_order

*Name String*::
VK_AMD_rasterization_order
+VK_AMD_rasterization_order+
*Extension Type*::
Device extension
*Registered Extension Number*::
Expand All @@ -16,7 +16,8 @@
*Dependencies*::
- This extension is written against version 1.0.11 of the Vulkan API.
*Contributors*::
- Matthaeus G. Chajdas, AMD
- Matthaeus G.
Chajdas, AMD
- Jaakko Konttinen, AMD
- Daniel Rakos, AMD
- Graham Sellers, AMD
Expand All @@ -25,8 +26,9 @@
- Daniel Rakos, AMD

This extension introduces the possibility for the application to control the
order of primitive rasterization. In unextended Vulkan, the following
stages are guaranteed to execute in _API order_:
order of primitive rasterization.
In unextended Vulkan, the following stages are guaranteed to execute in _API
order_:

* depth bounds test
* stencil test, stencil op, and stencil write
Expand All @@ -35,16 +37,18 @@ stages are guaranteed to execute in _API order_:
* blending, logic op, and color write

This extension enables applications to opt into a relaxed, implementation
defined primitive rasterization order that may allow better parallel processing
of primitives and thus enabling higher primitive throughput. It is applicable in
cases where the primitive rasterization order is known to not affect the output
of the rendering or any differences caused by a different rasterization order
are not a concern from the point of view of the application's purpose.
defined primitive rasterization order that may allow better parallel
processing of primitives and thus enabling higher primitive throughput.
It is applicable in cases where the primitive rasterization order is known
to not affect the output of the rendering or any differences caused by a
different rasterization order are not a concern from the point of view of
the application's purpose.

A few examples of cases when using the relaxed primitive rasterization order
would not have an effect on the final rendering:

* If the primitives rendered are known to not overlap in framebuffer space.
* If the primitives rendered are known to not overlap in framebuffer
space.
* If depth testing is used with a comparison operator of
ename:VK_COMPARE_OP_LESS, ename:VK_COMPARE_OP_LESS_OR_EQUAL,
ename:VK_COMPARE_OP_GREATER, or ename:VK_COMPARE_OP_GREATER_OR_EQUAL,
Expand Down Expand Up @@ -75,14 +79,14 @@ None

=== Issues

1) How is this extension useful to application developers?
1) How is this extension useful to application developers?

RESOLVED: Allows them to increase primitive throughput for cases when
strict API order rasterization is not important due to the nature of the
content, the configuration used, or the requirements towards the output of
the rendering.
content, the configuration used, or the requirements towards the output
of the rendering.

2) How does this extension interact with content optimizations aiming to
2) How does this extension interact with content optimizations aiming to
reduce overdraw by appropriately ordering the input primitives?

RESOLVED: While the relaxed rasterization order might somewhat limit the
Expand All @@ -91,14 +95,15 @@ None
used so applications are still recommended to apply these optimizations
even if they intend to use the extension.

3) Are there any guarantees about the primitive rasterization order when
3) Are there any guarantees about the primitive rasterization order when
using the new relaxed mode?

RESOLVED: No. The rasterization order is completely implementation
dependent in this case but in practice it is expected to partially still
follow the order of incoming primitives.
RESOLVED: No.
The rasterization order is completely implementation dependent in this
case but in practice it is expected to partially still follow the order
of incoming primitives.

4) Does the new relaxed rasterization order have any adverse effect on
4) Does the new relaxed rasterization order have any adverse effect on
repeatability and other invariance rules of the API?

RESOLVED: Yes, in the sense that it extends the list of exceptions when
Expand Down
35 changes: 35 additions & 0 deletions doc/specs/vulkan/appendices/VK_AMD_shader_ballot.txt
@@ -0,0 +1,35 @@
[[VK_AMD_shader_ballot]]
== VK_AMD_shader_ballot

*Name String*::
+VK_AMD_shader_ballot+
*Extension Type*::
Device extension
*Registered Extension Number*::
38
*Last Modified Date*::
2016-09-19
*Revision*::
1
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0.27 of the Vulkan API.
*Contributors*::
- Qun Lin, AMD
- Graham Sellers, AMD
- Daniel Rakos, AMD
- Rex Xu, AMD
- Dominik Witczak, AMD
- Matthäus G. Chajdas, AMD
*Contacts*::
- Dominik Witczak, AMD (Dominik.Witczak@amd.com)

This extension adds support for the following SPIR-V extension in {apiname}:

* +SPV_AMD_shader_ballot+

=== Version History

* Revision 1, 2016-09-19 (Dominik Witczak)
- Initial draft
Expand Up @@ -2,7 +2,7 @@
== VK_AMD_shader_explicit_vertex_parameter

*Name String*::
VK_AMD_shader_explicit_vertex_parameter
+VK_AMD_shader_explicit_vertex_parameter+
*Extension Type*::
Device extension
*Registered Extension Number*::
Expand All @@ -16,7 +16,8 @@
*Dependencies*::
- This extension is written against version 1.0.11 of the Vulkan API.
*Contributors*::
- Matthaeus G. Chajdas, AMD
- Matthaeus G.
Chajdas, AMD
- Qun Lin, AMD
- Daniel Rakos, AMD
- Graham Sellers, AMD
Expand All @@ -26,7 +27,7 @@

This extension adds support for the following SPIR-V extension in {apiname}:

* SPV_AMD_shader_explicit_vertex_parameter
* +SPV_AMD_shader_explicit_vertex_parameter+

=== Version History

Expand Down

0 comments on commit 95dd2f3

Please sign in to comment.