Skip to content
Permalink
Browse files

Change log for March 10, 2017 Vulkan 1.0.43 spec update:

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

Github Issues:

  * Make clearer that color write mask is applied regardless of whether
    blending is enabled, by referring to the
    <<framebuffer-color-write-mask,Color Write Mask>> section (public issue
    241).
  * Fix public issue 414:
  ** Added two new command buffer states (invalid, pending), and an explicit
     "command buffer lifecycle" section to explain them.
  ** Replaced "pending execution" with "in the pending state".
  ** Replaced a bunch of "this will invalidate the command buffer" language
     with "this will move the command buffer to the invalid state", and added
     validation language for what state those command buffers should be in.
  ** Added additional validation language about what state a command buffer
     should be in for various commands that affect it.
  ** Added invalidation language to destroy commands in the lifetimes section
     of fundamentals.
  ** Added command buffers to list of objects which must not be deleted
     whilst a (primary) command buffer is in the recording or pending state.
  * Update `GL_KHR_vulkan_glsl` extension to allow anonymous push constant
    blocks (public issue 428).

Internal Issues:

  * Document rules about extension interactions in the style guide (internal
    issue 579).
  * Require ename:VK_PRESENT_MODE_MAILBOX_KHR support in queries of surfaces
    created with flink:vkCreateWaylandSurfaceKHR using the
    VK_KHR_wayland_surface extension (internal issue 666).
  * Remove Valid Usage constraints for flink:vkAllocateDescriptorSets when
    the `VK_KHR_maintainance1` extension is present (internal issue 686).
  * Remove undocumented KHX-variants of vkGetPhysicalDeviceProperties2KHR
    and vkGetPhysicalDeviceImageFormatProperties2KHR from the
    <<VK_KHX_external_memory_capabilities>> and
    <<VK_KHX_external_semaphore_capabilities>> extensions.

New Extensions:

  * `VK_EXT_hdr_metadata`
  * `VK_GOOGLE_display_timing`
  • Loading branch information...
oddhack committed Mar 11, 2017
1 parent fd0e4c3 commit 3e4bee3d115e4eb58cb6559af27ed769eccde393
Showing with 1,528 additions and 705 deletions.
  1. +47 −0 ChangeLog.txt
  2. +7 −5 doc/specs/misc/GL_KHR_vulkan_glsl.txt
  3. +1 −1 doc/specs/vulkan/Makefile
  4. +36 −2 doc/specs/vulkan/README.adoc
  5. +19 −16 doc/specs/vulkan/appendices/{VK_EXT_SMPTE2086_metadata.txt → VK_EXT_hdr_metadata.txt}
  6. +94 −0 doc/specs/vulkan/appendices/VK_GOOGLE_display_timing.txt
  7. +20 −2 doc/specs/vulkan/appendices/VK_KHR_wayland_surface.txt
  8. +1 −1 doc/specs/vulkan/appendices/VK_NVX_multiview_per_view_attributes.txt
  9. +1 −2 doc/specs/vulkan/appendices/VK_NV_sample_mask_override_coverage.txt
  10. +14 −3 doc/specs/vulkan/appendices/extensions.txt
  11. +18 −13 doc/specs/vulkan/chapters/{VK_EXT_SMPTE2086_metadata.txt → VK_EXT_hdr_metadata.txt}
  12. +63 −0 doc/specs/vulkan/chapters/VK_GOOGLE_display_timing/PresentTimeInfo.txt
  13. +254 −0 doc/specs/vulkan/chapters/VK_GOOGLE_display_timing/queries.txt
  14. +4 −0 doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt
  15. +7 −3 doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt
  16. +25 −3 doc/specs/vulkan/chapters/VK_KHR_wayland_surface/platformCreateSurface_wayland.txt
  17. +170 −90 doc/specs/vulkan/chapters/cmdbuffers.txt
  18. +34 −8 doc/specs/vulkan/chapters/descriptorsets.txt
  19. +3 −2 doc/specs/vulkan/chapters/devsandqueues.txt
  20. +28 −9 doc/specs/vulkan/chapters/features.txt
  21. +26 −22 doc/specs/vulkan/chapters/framebuffer.txt
  22. +7 −1 doc/specs/vulkan/chapters/fundamentals.txt
  23. +1 −1 doc/specs/vulkan/chapters/renderpass.txt
  24. +3 −3 doc/specs/vulkan/chapters/synchronization.txt
  25. +2 −1 doc/specs/vulkan/config/extDependency.py
  26. +2 −1 doc/specs/vulkan/config/extDependency.sh
  27. +35 −0 doc/specs/vulkan/style/extensions.txt
  28. +5 −0 doc/specs/vulkan/style/naming.txt
  29. +50 −40 src/ext_loader/vulkan_ext.c
  30. +1 −1 src/spec/extDependency.py
  31. +1 −1 src/spec/validitygenerator.py
  32. +467 −439 src/spec/vk.xml
  33. +82 −35 src/vulkan/vulkan.h
@@ -2010,3 +2010,50 @@ New Extensions:
* Add new GLSL vendor extensions to support new builtin variables:
** GL_EXT_device_group
** GL_EXT_multiview

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

Change log for March 10, 2017 Vulkan 1.0.43 spec update:

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

Github Issues:

* Make clearer that color write mask is applied regardless of whether
blending is enabled, by referring to the
<<framebuffer-color-write-mask,Color Write Mask>> section (public issue
241).
* Fix public issue 414:
** Added two new command buffer states (invalid, pending), and an explicit
"command buffer lifecycle" section to explain them.
** Replaced "pending execution" with "in the pending state".
** Replaced a bunch of "this will invalidate the command buffer" language
with "this will move the command buffer to the invalid state", and added
validation language for what state those command buffers should be in.
** Added additional validation language about what state a command buffer
should be in for various commands that affect it.
** Added invalidation language to destroy commands in the lifetimes section
of fundamentals.
** Added command buffers to list of objects which must not be deleted
whilst a (primary) command buffer is in the recording or pending state.
* Update `GL_KHR_vulkan_glsl` extension to allow anonymous push constant
blocks (public issue 428).

Internal Issues:

* Document rules about extension interactions in the style guide (internal
issue 579).
* Require ename:VK_PRESENT_MODE_MAILBOX_KHR support in queries of surfaces
created with flink:vkCreateWaylandSurfaceKHR using the
VK_KHR_wayland_surface extension (internal issue 666).
* Remove Valid Usage constraints for flink:vkAllocateDescriptorSets when
the `VK_KHR_maintainance1` extension is present (internal issue 686).
* Remove undocumented KHX-variants of vkGetPhysicalDeviceProperties2KHR
and vkGetPhysicalDeviceImageFormatProperties2KHR from the
<<VK_KHX_external_memory_capabilities>> and
<<VK_KHX_external_semaphore_capabilities>> extensions.

New Extensions:

* `VK_EXT_hdr_metadata`
* `VK_GOOGLE_display_timing`
@@ -33,8 +33,8 @@ Status

Version

Last Modified Date: 07-Feb-2017
Revision: 35
Last Modified Date: 13-Feb-2017
Revision: 36

Number

@@ -139,7 +139,7 @@ Overview
int member1;
float member2;
...
} InstanceName;
} InstanceName; // optional instance name

... = InstanceName.member2; // read a push constant

@@ -749,8 +749,8 @@ Changes to Chapter 4 of the OpenGL Shading Language Specification
compile-time error to apply this to anything other than a uniform block
declaration. The values in the block will be initialized through the
API, as per the Vulkan API specification. A block declared with
layout(push_constant) must have an /instance-name/ supplied, or a
compile-time error results. There can be only one push_constant
layout(push_constant) may optionally include an /instance-name/.
There can be only one push_constant
block per stage, or a compile-time or link-time error will result. A
push-constant array can only be indexed with dynamically uniform indexes.
Uniform blocks declared with push_constant use different resources
@@ -1355,6 +1355,8 @@ Revision History

Rev. Date Author Changes
---- ----------- ------- --------------------------------------------
36 13-Feb-2017 JohnK Fix public bug 428: allow anonymous
push_constant blocks.
35 07-Feb-2017 JohnK Add 'offset' and 'align' to all versions
34 26-Jan-2017 JohnK Allow the ternary operator to result in a
specialization constant
@@ -86,7 +86,7 @@ VERBOSE =
# $(EXTENSIONS))
# ADOCOPTS options for asciidoc->HTML5 output
NOTEOPTS = -a editing-notes -a implementation-guide
SPECREVISION = 1.0.42
SPECREVISION = 1.0.43
# Spell out RFC2822 format as not all date commands support -R
SPECDATE = $(shell echo `date -u "+%a, %d %b %Y %T %z"`)

@@ -52,6 +52,17 @@ make -j 8
may significantly speed up the reference page builds.


[[build-bugs]]
=== Asciidoctor Build Errors

If you see an error like this from the `pdf` target:

/home/jon/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/ruby-enum-0.7.1/lib/ruby-enum/enum.rb:34:in `const_set': asciidoctor: FAILED: /home/tree/git/vulkan/doc/specs/vulkan/vkspec.txt: Failed to load AsciiDoc document - wrong constant name default (NameError)

then try <<ruby-enum-downgrade,downgrading ruby-enum>>
as described below


[[building-extensions]]
=== Building With Extensions Included

@@ -67,8 +78,8 @@ extension names (e.g. `VK_KHR_surface`) in the Makefile variable
When changing the list of extensions, it is critical to remove all generated
files using the `clean_generated` Makefile target, as the contents of
generated files depends on `$(EXTENSIONS)`.
There are two helper scripts which clean these files and then build one or
more specified targets for specified extensions:
There are several helper scripts which clean these files and then build one
or more specified targets for specified extensions:

* `makeExt` - generate outputs with a single extension enabled.
Usage is `makeExt extension-name target(s)`, where `extension-name` is
@@ -80,6 +91,13 @@ more specified targets for specified extensions:
Khronox Experimental (`VK_KHX_*`) extensions enabled.
Usage is `makeKHRAndKHX target(s)`.

Before using these scripts, if you have changed `src/spec/vk.xml` since
checking out your repository, first

$ make config/extDependency.sh

to rebuild extension dependencies.

The Makefile variable `$(APITITLE)` defines an additional string which is
appended to the specification title.
When building with extensions enabled, this should be set to something like
@@ -710,10 +728,26 @@ MATHEMATICAL_SKIP_STRDUP=1 gem install asciidoctor-mathematical
gem install --pre asciidoctor-pdf
----

[[ruby-enum-downgrade]]
==== Ruby Gem Versioning Errors

As of 2017-03-06, there appears to be a problem with the ruby-enum version
0.7.1 gem which breaks the PDF build. Make sure you are using ruby-enum
0.7.0, as follows:

gem uninstall ruby-enum
gem install -v 0.7.0 ruby-enum

Hopefully this will soon be fixed. See
https://github.com/gjtorikian/mathematical/issues/69 for a report of this
problem.


[[history]]
== Revision History

* 2017-03-06 - Add description of ruby-enum versioning problem and how to
fix it.
* 2017-02-13 - Move some comments here from ../../../README.md. Tweak
asciidoctor markup to more clearly delineate shell command blocks.
* 2017-02-10 - Add more Ruby installation guidelines and reflow the
@@ -1,14 +1,14 @@
[[VK_EXT_SMPTE2086_metadata]]
== VK_EXT_SMPTE2086_metadata
[[VK_EXT_hdr_metadata]]
== VK_EXT_hdr_metadata

*Name String*::
+VK_EXT_SMPTE2086_metadata+
+VK_EXT_hdr_metadata+
*Extension Type*::
Device
*Registered Extension Number*::
106
*Last Modified Date*::
2017-01-06
2017-03-04
*Revision*::
1
*IP Status*::
@@ -22,14 +22,11 @@
- Courtney Goeltzenleuchter, Google

This extension defines two new structures and a function to assign SMPTE
(the Society of Motion Picture and Television Engineers) 2086 metadata to a
swapchain.
This is the Vulkan equivalent to the EGL_EXT_surface_SMPTE2086_metadata
extension.
The SMPTE 2086 metadata includes the color primaries, white point, and
luminance range of the mastering display, which all together define the
color volume that contains all the possible colors the mastering display can
produce.
(the Society of Motion Picture and Television Engineers) 2086 metadata and
CTA (Consumer Technology Assocation) 861.3 metadata to a swapchain.
The metadata includes the color primaries, white point, and luminance range
of the mastering display, which all together define the color volume that
contains all the possible colors the mastering display can produce.
The mastering display is the display where creative work is done and
creative intent is established.
To preserve such creative intent as much as possible and achieve consistent
@@ -38,21 +35,28 @@ display pipeline to know the color volume of the original mastering display
where content was created or tuned.
This avoids performing unnecessary mapping of colors that are not
displayable on the original mastering display.
The metadata also includes the maxContentLightLevel and
maxFrameAverageLightLevel as defined by CTA 861.3.

While the general purpose of the metadata is to assist in the transformation
between different color volumes of different displays and help achieve
better color reproduction, it is not in the scope of this extension to
define how exactly the metadata should be used in such a process.
It is up to the implementation to determine how to make use of the metadata.

=== New Enum Constants

* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_HDR_METADATA_EXT

=== New Structures

* slink:VkXYColorEXT
* slink:VkSMPTE2086MetadataEXT
* slink:VkHdrMetadataEXT

=== New Functions

* flink:vkSetSMPTE2086MetadataEXT
* flink:vkSetHdrMetadataEXT

=== Issues

@@ -63,8 +67,7 @@ It is up to the implementation to determine how to make use of the metadata.

2) Should we specify default if not specified by the application?

PROPOSED: No, that leaves the default up to the display or the
implementation which may be more typical.
PROPOSED: No, that leaves the default up to the display.

=== Version History

@@ -0,0 +1,94 @@
// Copyright (c) 2014-2016 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html

[[VK_GOOGLE_display_timing]]
== VK_GOOGLE_display_timing

*Name String*::
+VK_GOOGLE_display_timing+
*Extension Type*::
Device extension
*Registered Extension Number*::
93
*Last Modified Date*::
2017-02-14
*Revision*::
1
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
- This extension requires +VK_KHR_swapchain+.
*Contributors*::
- Ian Elliott, Google
- Jesse Hall, Google
*Contacts*::
- Ian Elliott, 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.
An application can use this to minimize various visual anomalies (e.g.
stuttering).

Traditional game and real-time animation applications need to correctly
position their geometry for when the presentable image will be presented to
the user.
To accomplish this, applications need various timing information about the
presentation engine's display.
They need to know when presentable images were actually presented, and when
they could have been presented.
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.

This extension treats variable-refresh-rate (VRR) displays as if they are
fixed-refresh-rate (FRR) displays.

=== New Object Types

None.

=== New Enum Constants

* Extending ename:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE

=== New Enums

None.

=== New Structures

* slink:VkRefreshCycleDurationGOOGLE
* slink:VkPastPresentationTimingGOOGLE
* slink:VkPresentTimesInfoGOOGLE
* slink:VkPresentTimeGOOGLE

=== New Functions

* flink:vkGetRefreshCycleDurationGOOGLE
* flink:vkGetPastPresentationTimingGOOGLE

=== Issues

None.

=== Examples

[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).
====

=== Version History

* Revision 1, 2017-02-14 (Ian Elliott)
- Internal revisions
@@ -13,7 +13,7 @@
*Last Modified Date*::
2015-11-28
*Revision*::
5
6
*IP Status*::
No known IP claims.
*Dependencies*::
@@ -44,7 +44,7 @@
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 the windows desktop.
well as a query to determine support for rendering to a Wayland compositor.

=== New Object Types

@@ -81,6 +81,18 @@ presentation to any slink:VkSurface for surfaces on the display.
flink:vkGetPhysicalDeviceWaylandPresentationSupportKHR was added to address
this issue.

2) Should we require surfaces created with flink:vkCreateWaylandSurfaceKHR
to support the ename:VK_PRESENT_MODE_MAILBOX_KHR present mode?

*RESOLVED*: Yes.
Wayland is an inherently mailbox window system and mailbox support is
required for some Wayland compositor interactions to work as expected.
While handling these interactions may be possible with
ename:VK_PRESENT_MODE_FIFO_KHR, it is much more difficult to do without
deadlock and requiring all Wayland applications to be able to support
implementations which only support ename:VK_PRESENT_MODE_FIFO_KHR would be
an onerous restriction on application developers.

=== Version History

* Revision 1, 2015-09-23 (Jesse Hall)
@@ -101,3 +113,9 @@ this issue.

* Revision 5, 2015-11-28 (Daniel Rakos)
- Updated the surface create function to take a pCreateInfo structure.

* Revision 6, 2017-02-08 (Jason Ekstrand)
- Added the requirement that implementations support
ename:VK_PRESENT_MODE_MAILBOX_KHR.
- Added wording about interactions between flink:vkQueuePresentKHR and
the Wayland requests sent to the compositor.

0 comments on commit 3e4bee3

Please sign in to comment.
You can’t perform that action at this time.