Change log for October 7, 2018 Vulkan 1.1.87 spec update:

  * Update release number to 87.

Public Issues:

  * Merge flink:vkCmdPipelineBarrier self-dependency barrier VUs referring
    to the same subpass dependency (public pull request 756).
  * Describe default value of `"optional"` attribute in the registry schema
    document (public issue 769)
  * Fix links in <<VK_NVX_raytracing>> extension (public pull request 805).
  * Mark the <<VK_KHR_mir_surface>> extension obsolete (see public issue 814
    - does not close this, however).
  * Fix missing endif in Image Creation block (public issue 817).

Internal Issues:

  * Clarify that the compressed texture formats corresponding to
    <<features-features-textureCompressionETC2>>,
    <<features-features-textureCompressionASTC_LDR>>, and
    <<features-features-textureCompressionBC>> is not contingent on the
    feature bits, and may be supported even if the features are not enabled
    (internal issue 663).
  * Clarify that code:FragStencilRefEXT is output only in the
    <<interfaces-builtin-variables, Built-In Variables>> section (internal
    issue 1173).
  * Identify and correct many overly-aggressive uses of "`undefined`", and
    narrow them down, where straightforward to do so. Mark such resolved
    uses of "`undefined`" with the custom undefined: macro. Add a new
    <<writing-undefined, Describing Undefined Behavior>> section (internal
    issue 1267).
  * Don't require code:inline_uniform_block descriptors to be populated
    before use in the flink:vkAllocateDescriptorSets section (internal issue
    1380).
  * Allow suppressing inline SVG images by controlling this with an
    attribute set in the Makefile, rather than the explicit [%inline]
    directive (internal issue 1391).
  * Mark 'Khronos' as a registered trademark in several places, now that it
    is one.
  * Fix typo in the <<VK_KHR_shader_atomic_int64>> appendix using the GLSL
    naming of the compare exchange op when referring to the SPIR-V op.
  * Specify in the flink:vkGetPhysicalDeviceQueueFamilyProperties section
    that all implementations must support at least one queue family, and
    that every queue family must contain at least one queue.
  * Make slink:VkPipelineDynamicStateCreateInfo::pname:dynamicStateCount,
    slink:VkSampleLocationsInfoEXT::pname:sampleLocationsPerPixel, and
    slink:VkSampleLocationsInfoEXT::pname:sampleLocationsCount optional, to
    fix bogus implicit valid usage checks that were causing failures in the
    conformance tests.
  * Fix vendor tag in reserved extension 237 constants. Does not affect
    anything since it's just a placeholder, but this should avoid further
    comments.
  * Minor markup fixes in some extension appendices.

New Extensions:

  * `<<VK_FUCHSIA_imagepipe_surface>>`

ChangeLog.txt

@@ -8,6 +8,66 @@ public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for October 7, 2018 Vulkan 1.1.87 spec update:
+
+  * Update release number to 87.
+
+Public Issues:
+
+  * Merge flink:vkCmdPipelineBarrier self-dependency barrier VUs referring
+    to the same subpass dependency (public pull request 756).
+  * Describe default value of `"optional"` attribute in the registry schema
+    document (public issue 769)
+  * Fix links in <<VK_NVX_raytracing>> extension (public pull request 805).
+  * Mark the <<VK_KHR_mir_surface>> extension obsolete (see public issue 814
+    - does not close this, however).
+  * Fix missing endif in Image Creation block (public issue 817).
+
+Internal Issues:
+
+  * Clarify that the compressed texture formats corresponding to
+    <<features-features-textureCompressionETC2>>,
+    <<features-features-textureCompressionASTC_LDR>>, and
+    <<features-features-textureCompressionBC>> is not contingent on the
+    feature bits, and may be supported even if the features are not enabled
+    (internal issue 663).
+  * Clarify that code:FragStencilRefEXT is output only in the
+    <<interfaces-builtin-variables, Built-In Variables>> section (internal
+    issue 1173).
+  * Identify and correct many overly-aggressive uses of "`undefined`", and
+    narrow them down, where straightforward to do so. Mark such resolved
+    uses of "`undefined`" with the custom undefined: macro. Add a new
+    <<writing-undefined, Describing Undefined Behavior>> section (internal
+    issue 1267).
+  * Don't require code:inline_uniform_block descriptors to be populated
+    before use in the flink:vkAllocateDescriptorSets section (internal issue
+    1380).
+  * Allow suppressing inline SVG images by controlling this with an
+    attribute set in the Makefile, rather than the explicit [%inline]
+    directive (internal issue 1391).
+  * Mark 'Khronos' as a registered trademark in several places, now that it
+    is one.
+  * Fix typo in the <<VK_KHR_shader_atomic_int64>> appendix using the GLSL
+    naming of the compare exchange op when referring to the SPIR-V op.
+  * Specify in the flink:vkGetPhysicalDeviceQueueFamilyProperties section
+    that all implementations must support at least one queue family, and
+    that every queue family must contain at least one queue.
+  * Make slink:VkPipelineDynamicStateCreateInfo::pname:dynamicStateCount,
+    slink:VkSampleLocationsInfoEXT::pname:sampleLocationsPerPixel, and
+    slink:VkSampleLocationsInfoEXT::pname:sampleLocationsCount optional, to
+    fix bogus implicit valid usage checks that were causing failures in the
+    conformance tests.
+  * Fix vendor tag in reserved extension 237 constants. Does not affect
+    anything since it's just a placeholder, but this should avoid further
+    comments.
+  * Minor markup fixes in some extension appendices.
+
+New Extensions:
+
+  * `<<VK_FUCHSIA_imagepipe_surface>>`
+
+-----------------------------------------------------
+
 Change log for September 29, 2018 Vulkan 1.1.86 spec update:
 
   * Update release number to 86.
@@ -2536,7 +2596,7 @@ Internal Issues:
 
 Other Issues:
 
-  * Vulkan(R) is now a registered trademark symbol, and this is reflected in
+  * Vulkan is now a registered trademark symbol, and this is reflected in
     documents and copyright statements.
 
 -----------------------------------------------------

Makefile

@@ -46,6 +46,11 @@ EXTOPTIONS := $(foreach ext,$(EXTS),-extension $(ext))
 # normally used when building with extensions included.
 APITITLE =
 
+# IMAGEOPTS is normally set to generate inline SVG images, but can be
+# overridden to an empty string, since the inline option doesn't work
+# well with our HTML diffs.
+IMAGEOPTS = inline
+
 # The default 'all' target builds the following sub-targets:
 #  html - HTML single-page API specification
 #  pdf - PDF single-page API specification
@@ -107,7 +112,7 @@ VERBOSE =
 # EXTRAATTRIBS sets additional attributes, if passed to make
 # ADOCOPTS   options for asciidoc->HTML5 output
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 86
+PATCHVERSION = 87
 ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
 SPECREVISION = 1.1.$(PATCHVERSION)
 else
@@ -132,6 +137,7 @@ ATTRIBOPTS   = -a revnumber="$(SPECREVISION)" \
 	       -a revremark="$(SPECREMARK)" \
 	       -a apititle="$(APITITLE)" \
 	       -a stem=latexmath \
+	       -a imageopts="$(IMAGEOPTS)" \
 	       $(VERSIONATTRIBS) \
 	       $(EXTATTRIBS) \
 	       $(EXTRAATTRIBS)

appendices/VK_EXT_debug_utils.txt

@@ -325,15 +325,15 @@ submitted.
 
 1) Should we just name this extension `VK_EXT_debug_report2`
 
-**RESOLVED**: No.
+*RESOLVED*: No.
 There is enough additional changes to the structures to break backwards
 compatibility.
 So, a new name was decided that would not indicate any interaction with the
 previous extension.
 
 2) Will validation layers immediately support all the new features.
 
-**RESOLVED**: Not immediately.
+*RESOLVED*: Not immediately.
 As one can imagine, there is a lot of work involved with converting the
 validation layer logging over to the new functionality.
 Basic logging, as seen in the origin
@@ -347,7 +347,7 @@ exposed.
 3) If the validation layers won't expose the new functionality immediately,
 then what's the point of this extension?
 
-**RESOLVED**: We needed a replacement for
+*RESOLVED*: We needed a replacement for
 <<VK_EXT_debug_report,VK_EXT_debug_report>> because the
 elink:VkDebugReportObjectTypeEXT enumeration will no longer be updated and
 any new objects will need to be debugged using the new functionality
@@ -358,8 +358,7 @@ is an instance extension providing the callback functionality, and another
 device extension providing the general debug marker and annotation
 functionality)?
 
-**RESOLVED**: No, the functionality for this extension is too closely
-related.
+*RESOLVED*: No, the functionality for this extension is too closely related.
 If we did split up the extension, where would the structures and enums live,
 and how would you define that the device behavior in the instance extension
 is really only valid if the device extension is enabled, and the

appendices/VK_EXT_depth_range_unrestricted.txt

@@ -16,26 +16,32 @@ Finally it removes the restriction on the pname:depth value in
 slink:VkClearDepthStencilValue.
 
 === New Object Types
+
 None.
 
 === New Enum Constants
+
 None.
 
 === New Enums
+
 None.
 
 === New Structures
+
 None.
 
 === New Functions
+
 None.
 
 === Issues
+
 1) How do slink:VkViewport pname:minDepth and pname:maxDepth values outside
 of the `0.0` to `1.0` range interact with
 <<vertexpostproc-clipping,Primitive Clipping>>?
 
-**RESOLVED**: The behavior described in <<vertexpostproc-clipping,Primitive
+*RESOLVED*: The behavior described in <<vertexpostproc-clipping,Primitive
 Clipping>> still applies.
 If depth clamping is disabled the depth values are still clipped to [eq]#0
 {leq} z~c~ {leq} w~c~# before the viewport transform.
@@ -47,9 +53,10 @@ the `0.0` to `1.0` range.
 2) What happens if a resulting depth fragment is outside of the `0.0` to
 `1.0` range and the depth buffer is fixed-point rather than floating-point?
 
-**RESOLVED**: The supported range of a fixed-point depth buffer is `0.0` to
+*RESOLVED*: The supported range of a fixed-point depth buffer is `0.0` to
 `1.0` and depth fragments are clamped to this range.
 
 === Version History
+
   * Revision 1, 2017-06-22 (Piers Daniell)
     - Internal revisions

appendices/VK_EXT_external_memory_host.txt

@@ -65,7 +65,7 @@ However, usual synchronization requirements apply.
 
 RESOLVED: No, it violates valid usage conditions.
 Using the memory object imported from a host allocation that's already freed
-thus results in undefined behavior.
+thus results in undefined: behavior.
 
 4) Is flink:vkMapMemory expected to return the same host address which was
 specified when importing it to the memory object?
@@ -89,7 +89,7 @@ physical device?
 
 RESOLVED: No, at least not guaranteed by this extension.
 Some platforms do not allow locking the same physical pages for device
-access multiple times, so attempting to do it may result in undefined
+access multiple times, so attempting to do it may result in undefined:
 behavior.
 
 7) Does this extension support exporting the new handle type?