Skip to content
Permalink
Browse files

Change log for December 16, 2018 Vulkan 1.1.96 spec update:

  * Update release number to 96.

Public Issues:

  * Fix typo in `vk.xml` for `structextends` attribute of
    slink:VkPhysicalDeviceShadingRateImagePropertiesNV (public PR 870).
  * Fix links in optimized PDF output (public PR 879).

Internal Issues:

  * Add a link to GitHub contributors in the <<credits, Other Credits>>
    section (internal issue 808).
  * Clarify the behavior of command aliases described in the <<versions,Core
    Revisions>> and <<initialization-functionpointers, Command Function
    Pointers>> sections and the registry schema document with respect to
    whether they are or are not the same entry point, and what the behaviour
    of the ftext:vkGet*ProcAddr commands is for each alias (internal issue
    1462).
  * Update slink:VkPipelineShaderStageCreateInfo valid usage statements for
    writing to code:Layer and code:viewportIndex to apply to any vertex
    processing stage (internal issue 1475).
  * Make sparse image creation optional for Y'C~B~C~R~ formats in the
    <<features-required-format-support, Required Format Support>> section
    and the <<features-formats-requiring-sampler-ycbcr-conversion, Formats
    requiring sampler Y'C~B~C~R~ conversion for
    ename:VK_IMAGE_ASPECT_COLOR_BIT image views>> table (internal issue
    1476).
  * Modify the valid usage statement for
    flink:vkCmdDrawIndirectByteCountEXT::pname:vertexStride to use the
    pname:maxTransformFeedbackBufferDataStride limit rather than the
    pname:maxVertexInputBindingStride limit, which is a better match for
    transform feedback related operations (internal issue 1487).
  * Changed all members of slink:VkPhysicalDevicePCIBusInfoPropertiesEXT to
    have the `uint32_t` type. This is an imcompatible change to an EXT
    that's very recently released; although this is against usual Vulkan WG
    policy, we discussed and consider this an acceptable risk, but have
    polled the mesa-dev list in case there are use cases we missed (internal
    issue 1492).
  * Set spec vetsion to 1 for `VK_GOOGLE_hlsl_functionality1` and
    `VK_GOOGLE_decorate_string` in `vk.xml` (internal MR 2948).
  * Remove redundant valid usage statement `VkImageCreateInfo-pNext-02395`
    (internal MR 2950).
  * Add `check_spec_links.py` script, use it in Gitlab CI, and fix many
    minor markup issues discovered by the script (internal MR 2955).
  * Update `BUILD.md` to the current Ruby version (2.5.3), and make some
    corresponding updates to per-platform build instructions (internal MR
    2956).
  * Fix binding numbers and other details in
    flink:vkUpdateDescriptorSetWithTemplate.txt example code blocks
    (internal MR 2960).
  * Remove some nautovalidity="true" in `vk.xml` for NV extensions where
    it's clearly wrong (internal MR 2970).
  • Loading branch information...
oddhack committed Dec 17, 2018
1 parent 56c5c69 commit b557dd2167a5b2c92a03a69b34ff7a4431cca7ad
Showing with 2,458 additions and 211 deletions.
  1. +4 −0 .gitignore
  2. +10 −1 .gitlab-ci.yml
  3. +23 −29 BUILD.adoc
  4. +1 −1 Makefile
  5. +1 −1 appendices/VK_EXT_conservative_rasterization.txt
  6. +1 −1 appendices/VK_EXT_discard_rectangles.txt
  7. +1 −1 appendices/VK_EXT_display_surface_counter.txt
  8. +3 −1 appendices/VK_EXT_pci_bus_info.txt
  9. +1 −1 appendices/VK_EXT_transform_feedback.txt
  10. +1 −1 appendices/VK_EXT_validation_cache.txt
  11. +4 −4 appendices/VK_KHR_external_memory.txt
  12. +2 −2 appendices/VK_NVX_device_generated_commands.txt
  13. +1 −1 appendices/VK_NV_fragment_coverage_to_color.txt
  14. +1 −1 appendices/VK_NV_framebuffer_mixed_samples.txt
  15. +1 −1 appendices/VK_NV_viewport_swizzle.txt
  16. +6 −3 appendices/credits.txt
  17. +30 −13 appendices/versions.txt
  18. +1 −1 chapters/VK_KHR_swapchain/wsi.txt
  19. +2 −2 chapters/VK_NVX_device_generated_commands/generation.txt
  20. +3 −3 chapters/VK_NVX_device_generated_commands/objecttable.txt
  21. +1 −1 chapters/VK_NV_ray_tracing/raytracing-resources.txt
  22. +2 −2 chapters/VK_NV_ray_tracing/raytracing.txt
  23. +27 −32 chapters/descriptorsets.txt
  24. +3 −2 chapters/devsandqueues.txt
  25. +2 −2 chapters/drawing.txt
  26. +1 −1 chapters/extensions.txt
  27. +35 −22 chapters/features.txt
  28. +3 −3 chapters/fundamentals.txt
  29. +16 −1 chapters/initialization.txt
  30. +19 −9 chapters/memory.txt
  31. +8 −9 chapters/pipelines.txt
  32. +3 −3 chapters/primsrast.txt
  33. +1 −1 chapters/queries.txt
  34. +18 −18 chapters/renderpass.txt
  35. +7 −15 chapters/resources.txt
  36. +8 −8 include/vulkan/vulkan_core.h
  37. +1 −1 reflow_count.py
  38. +16 −3 registry.txt
  39. +2,047 −0 xml/check_spec_links.py
  40. +133 −0 xml/test_check_spec_links.py
  41. +10 −10 xml/vk.xml
@@ -65,3 +65,7 @@ xml/diag.txt

# Auto-generated files
# */timeMarker

# check_spec_links (and its tests) output
applyfixes.sh
xml/.cache
@@ -5,11 +5,20 @@ spec-generate:
stage: build
before_script:
- apt-get update -qq
- apt-get install -y -qq gcc git python3 ruby
- apt-get install -y -qq gcc git python3 python3-termcolor python3-pytest ruby
- apt-get install -y -qq cmake bison flex libffi-dev libxml2-dev libgdk-pixbuf2.0-dev libcairo2-dev libpango1.0-dev ttf-lyx
- gem install asciidoctor asciidoctor-mathematical coderay json-schema
script:
- ./makeAllExts QUIET= -j${nproc} -Otarget html styleguide registry manhtmlpages checkinc checklinks validusage
# Internal self-test of the script
- ( cd xml && py.test-3 )
- xml/check_spec_links.py --html=out/checks/problems.html > /dev/null || true
# Breaking the build if # of errors increases. We should manually ratchet ignore_count down as errors get fixed.
# If there are unfixable errors, add '--ignore_count #' where '#' is the
# number of them. This is a slightly crude way of enforcing "don't add
# errors" but simpler than the alternatives (running against master,
# diff, etc)
- xml/check_spec_links.py -Werror
artifacts:
when: always
paths:
@@ -427,7 +427,7 @@ work at least as well.

* GNU make (`make` version: 4.0.8-1; older versions probably OK)
* Python 3 (`python`, version: 3.4.2)
* Ruby (`ruby`, version: 2.3.3)
* Ruby (`ruby`, version: 2.5.3)
** The Ruby development package (`ruby-dev`) may also be required in some
environments.
* Git command-line client (`git`, version: 2.1.4).
@@ -448,9 +448,10 @@ environment managers below.
Please read the remainder of this document (other than platform-specific
parts you don't use) completely before trying to install.

* Asciidoctor (`asciidoctor`, version: 1.5.6.1)
* Asciidoctor (`asciidoctor`, version: 1.5.8)
* Coderay (`coderay`, version 1.1.2)
* JSON Schema (`json-schema`, version 2.8.0)
* JSON Schema (`json-schema`, version 2.8.1)
* Asciidoctor Diagram (`asciidoctor-diagram`, version: 1.5.11)
* Asciidoctor PDF (`asciidoctor-pdf`, version: 1.5.0.alpha16)
* Asciidoctor Mathematical (`asciidoctor-mathematical`, version 0.2.2)
* https://github.com/asciidoctor/asciidoctor-mathematical#dependencies[Dependencies
@@ -468,8 +469,8 @@ parts you don't use) completely before trying to install.
====
Older versions of these packages may work, but are not recommended.
In particular, the latest versions of `asciidoctor-pdf` and
`asciidoctor-mathematical` contain important patches working around issues
we've discovered, and those patches may not be present in earlier versions.
`asciidoctor-mathematical` often solve problems we've encountered in older
versions.
====

Only the `asciidoctor` and `coderay` gems are needed for the HTML `make`
@@ -669,7 +670,7 @@ System dependencies can be installed via apt:
----
sudo apt install build-essential python3 git cmake bison flex \
libffi-dev libxml2-dev libgdk-pixbuf2.0-dev libcairo2-dev \
libpango1.0-dev fonts-lyx ghostscript
libpango1.0-dev fonts-lyx ghostscript libreadline-dev
----

[NOTE]
@@ -733,11 +734,8 @@ The following ruby gems can be installed directly via the `gem install`
command, once the platform is set up:

----
gem install asciidoctor coderay json-schema
# Required only for pdf builds
gem install asciidoctor-mathematical
gem install --pre asciidoctor-pdf
gem install --no-rdoc --no-ri asciidoctor coderay json-schema asciidoctor-mathematical asciidoctor-diagram
gem install --no-rdoc --no-ri --pre asciidoctor-pdf
----

Depending on Ruby environment `gem` may require `sudo`.
@@ -748,7 +746,7 @@ by passing `--no-rdoc --no-ri` arguments.
It may be beneficial to use updated packages via:

----
gem update
gem update --no-rdoc --no-ri
gem clean
----

@@ -829,7 +827,7 @@ If you already have the gem dependencies previously installed, if there are
new versions, then updating to them instead might help:

----
$ gem update
$ gem update --no-rdoc --no-ri
----

*ruby-enum*
@@ -913,7 +911,6 @@ version of Ruby environment.
[NOTE]
.Note
====
* If you are new to Ruby, you should *completely remove* (through the
package manager, e.g. `sudo apt purge *packagename*`) all existing
Ruby and asciidoctor infrastructure on your machine before trying to use
@@ -968,7 +965,7 @@ sudo apt-get install autoconf bison build-essential libssl-dev \
libffi-dev libgdbm3 libgdbm-dev cmake libxml2 \
libxml2-dev flex pkg-config libglib2.0-dev \
libcairo-dev libpango1.0-dev libgdk-pixbuf2.0-dev \
libpangocairo-1.0
libpangocairo-1.0 libreadline-dev
# Install rbenv from https://github.com/rbenv/rbenv
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
@@ -990,27 +987,22 @@ echo 'eval "$(rbenv init -)"' >> .bashrc
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
# Install Ruby 2.3.3
# This takes in excess of 20 min. to build!
# Install Ruby 2.5.3 (current as of this writing; earlier may work)
# Setting RUBY_CONFIGURE_OPTS dramatically cuts the install time, see
# https://github.com/rbenv/ruby-build/issues/1054#issuecomment-276934761
# suggests:
# "You can speed up Ruby installs by avoiding generating ri/RDoc
# documentation for them:
# RUBY_CONFIGURE_OPTS=--disable-install-doc rbenv install 2.3.3
# We have not tried this.
RUBY_CONFIGURE_OPTS=--disable-install-doc
export RUBY_CONFIGURE_OPTS
rbenv install 2.5.3
rbenv install 2.3.3
# Configure rbenv globally to always use Ruby 2.3.3.
echo "2.3.3" > ~/.rbenv/version
# Configure rbenv globally to always use Ruby 2.5.3.
echo "2.5.3" > ~/.rbenv/version
# Finally, install toolchain components.
# asciidoctor-mathematical also takes in excess of 20 min. to build!
# The same RUBY_CONFIGURE_OPTS advice above may apply here as well.
gem install asciidoctor coderay json-schema
gem install --pre asciidoctor-pdf
MATHEMATICAL_SKIP_STRDUP=1 gem install asciidoctor-mathematical
gem install --no-rdoc --no-ri asciidoctor coderay json-schema asciidoctor-mathematical asciidoctor-diagram
gem install --no-rdoc --no-ri --pre asciidoctor-pdf
----


@@ -1035,6 +1027,8 @@ correctly on future launches.
[[history]]
== Revision History

* 2018-12-04 - Update Rbenv and ruby gem installation instructions and
package dependencies for Linux and Ubuntu/Windows 10.
* 2018-10-25 - Update Troubleshooting, and Windows and Linux build. Plus
random editing.
* 2018-03-13 - Rename to BUILD.adoc and update for new directory
@@ -115,7 +115,7 @@ VERBOSE =
# ADOCOPTS options for asciidoc->HTML5 output

NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 95
PATCHVERSION = 96
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else
@@ -52,7 +52,7 @@ None.

=== New Enums

* elink:VkPipelineRasterizationConservativeStateCreateFlagsEXT
* tlink:VkPipelineRasterizationConservativeStateCreateFlagsEXT
* elink:VkConservativeRasterizationModeEXT

=== New Structures
@@ -47,7 +47,7 @@ None.

=== New Enums

* elink:VkPipelineDiscardRectangleStateCreateFlagsEXT
* tlink:VkPipelineDiscardRectangleStateCreateFlagsEXT
* elink:VkDiscardRectangleModeEXT

=== New Structures
@@ -23,7 +23,7 @@ slink:VkSurfaceKHR object.

=== New Enums

* elink:VkSurfaceCounterFlagsEXT
* tlink:VkSurfaceCounterFlagsEXT
* elink:VkSurfaceCounterFlagBitsEXT

=== New Structures
@@ -1,7 +1,7 @@
include::meta/VK_EXT_pci_bus_info.txt[]

*Last Modified Date*::
2018-10-11
2018-12-10
*IP Status*::
No known IP claims.
*Contributors*::
@@ -53,5 +53,7 @@ None.

=== Version History

* Revision 2, 2018-12-10 (Daniel Rakos)
- Changed all members of the new structure to have the uint32_t type
* Revision 1, 2018-10-11 (Daniel Rakos)
- Initial revision
@@ -80,7 +80,7 @@ None.

=== New Enums

* elink:VkPipelineRasterizationStateStreamCreateFlagsEXT
* tlink:VkPipelineRasterizationStateStreamCreateFlagsEXT

=== New Structures

@@ -32,7 +32,7 @@ slink:VkShaderModule.
=== New Enums

* elink:VkValidationCacheHeaderVersionEXT
* elink:VkValidationCacheCreateFlagsEXT
* tlink:VkValidationCacheCreateFlagsEXT

=== New Structures

@@ -125,9 +125,9 @@ Options for defining this transition include:
* A new structure that can be added to the pname:pNext list in
slink:VkMemoryBarrier, slink:VkBufferMemoryBarrier, and
slink:VkImageMemoryBarrier.
* A new bit in elink:VkAccessFlags that can be set to indicate an
* A new bit in tlink:VkAccessFlags that can be set to indicate an
"`external`" access.
* A new bit in elink:VkDependencyFlags
* A new bit in tlink:VkDependencyFlags
* A new special queue family that represents an "`external`" queue.

A new structure has the advantage that the type of external transition can
@@ -144,11 +144,11 @@ purpose.
However, there is no obvious pipeline stage that would correspond to an
external access, and therefore no clear way to use
ename:VK_ACCESS_MEMORY_READ_BIT or ename:VK_ACCESS_MEMORY_WRITE_BIT.
elink:VkDependencyFlags and elink:VkPipelineStageFlags operate at command
tlink:VkDependencyFlags and tlink:VkPipelineStageFlags operate at command
granularity rather than image or buffer granularity, which would make an
entire pipeline barrier an internal->external or external->internal barrier.
This may not be a problem in practice, but seems like the wrong scope.
Another downside of elink:VkDependencyFlags is that it lacks inherent
Another downside of tlink:VkDependencyFlags is that it lacks inherent
directionality: There are not ptext:src and ptext:dst variants of it in the
barrier or dependency description semantics, so two bits might need to be
added to describe both internal->external and external->internal
@@ -83,8 +83,8 @@ etc.).

=== New Flag Types

* elink:VkIndirectCommandsLayoutUsageFlagsNVX
* elink:VkObjectEntryUsageFlagsNVX
* tlink:VkIndirectCommandsLayoutUsageFlagsNVX
* tlink:VkObjectEntryUsageFlagsNVX

=== New Enum Constants

@@ -30,7 +30,7 @@ None.

=== New Enums

* elink:VkPipelineCoverageToColorStateCreateFlagsNV
* tlink:VkPipelineCoverageToColorStateCreateFlagsNV

=== New Structures

@@ -57,7 +57,7 @@ None.
=== New Enums

* elink:VkCoverageModulationModeNV
* elink:VkPipelineCoverageModulationStateCreateFlagsNV
* tlink:VkPipelineCoverageModulationStateCreateFlagsNV

=== New Structures

@@ -38,7 +38,7 @@ None.
=== New Enums

* elink:VkViewportCoordinateSwizzleNV
* elink:VkPipelineViewportSwizzleStateCreateFlagsNV
* tlink:VkPipelineViewportSwizzleStateCreateFlagsNV

=== New Structures

@@ -228,9 +228,12 @@ their name.

== Other Credits

In addition to the Working Group, the Vulkan Advisory Panel members provided
important real-world usage information and advice that helped guide design
decisions.
The Vulkan Advisory Panel members provided important real-world usage
information and advice that helped guide design decisions.

The wider Vulkan community have provided useful feedback, questions and spec
changes that have helped improve the quality of the Specification via
link:https://github.com/KhronosGroup/Vulkan-Docs/graphs/contributors[GitHub].

Administrative support to the Working Group for Vulkan 1.1 was provided by
Khronos staff including Angela Cheng, Ann Thorsnes, Emily Stearns, Liz
@@ -20,6 +20,23 @@ Any differences between the core and extension version of the functionality
will be documented in the extension appendix, and mentioned briefly in the
version description in this appendix.

[NOTE]
.Note
====
For structure and enumeration aliases, the aliased extension type is
semantically identical to the new core type.
The C99 headers simply `typedef` the aliases to the core types.

For command aliases, however, there are two separate entry point
definitions, due to the fact that the C99 ABI has no way to alias command
definitions without resorting to the preprocessor.
Calling via either entry point definition will produce identical behavior
within the bounds of the specification, and should still invoke the same
entry point in the implementation.
Debug tools may use separate entry points with different debug behavior; to
write the appropriate command name to an output log, for instance.
====

It's possible to build the specification for earlier versions, but to aid
readability of the latest versions, this appendix gives an overview of the
changes as compared to earlier versions.
@@ -231,19 +248,19 @@ command to <<vkEnumerateInstanceVersion, enumerate the instance version>>.
* elink:VkSemaphoreImportFlagBits
* elink:VkSubgroupFeatureFlagBits
* elink:VkTessellationDomainOrigin
* elink:VkCommandPoolTrimFlags
* elink:VkDescriptorUpdateTemplateCreateFlags
* elink:VkExternalFenceFeatureFlags
* elink:VkExternalFenceHandleTypeFlags
* elink:VkExternalMemoryFeatureFlags
* elink:VkExternalMemoryHandleTypeFlags
* elink:VkExternalSemaphoreFeatureFlags
* elink:VkExternalSemaphoreHandleTypeFlags
* elink:VkFenceImportFlags
* elink:VkMemoryAllocateFlags
* elink:VkPeerMemoryFeatureFlags
* elink:VkSemaphoreImportFlags
* elink:VkSubgroupFeatureFlags
* tlink:VkCommandPoolTrimFlags
* tlink:VkDescriptorUpdateTemplateCreateFlags
* tlink:VkExternalFenceFeatureFlags
* tlink:VkExternalFenceHandleTypeFlags
* tlink:VkExternalMemoryFeatureFlags
* tlink:VkExternalMemoryHandleTypeFlags
* tlink:VkExternalSemaphoreFeatureFlags
* tlink:VkExternalSemaphoreHandleTypeFlags
* tlink:VkFenceImportFlags
* tlink:VkMemoryAllocateFlags
* tlink:VkPeerMemoryFeatureFlags
* tlink:VkSemaphoreImportFlags
* tlink:VkSubgroupFeatureFlags


=== New Structures
@@ -296,7 +296,7 @@ endif::VK_KHR_shared_presentable_image[]
* [[VUID-VkSwapchainCreateInfoKHR-imageSharingMode-01277]]
If pname:imageSharingMode is ename:VK_SHARING_MODE_CONCURRENT,
pname:pQueueFamilyIndices must: be a valid pointer to an array of
pname:queueFamilyIndexCount basetype:uint32_t values
pname:queueFamilyIndexCount code:uint32_t values
* [[VUID-VkSwapchainCreateInfoKHR-imageSharingMode-01278]]
If pname:imageSharingMode is ename:VK_SHARING_MODE_CONCURRENT,
pname:queueFamilyIndexCount must: be greater than `1`
@@ -100,13 +100,13 @@ include::../../api/structs/VkCmdProcessCommandsInfoNVX.txt[]
If pname:targetCommandBuffer is `NULL` an implicit reservation as well
as execution takes place on the processing sname:VkCommandBuffer.
* pname:sequencesCountBuffer can: be slink:VkBuffer from which the actual
amount of sequences is sourced from as ftext:uint32_t value.
amount of sequences is sourced from as code:uint32_t value.
* pname:sequencesCountOffset is the byte offset into
pname:sequencesCountBuffer where the count value is stored.
* pname:sequencesIndexBuffer must: be set if
pname:indirectCommandsLayout's
ename:VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NVX is set
and provides the used sequence indices as ftext:uint32_t array.
and provides the used sequence indices as code:uint32_t array.
Otherwise it must: be dlink:VK_NULL_HANDLE.
* pname:sequencesIndexOffset is the byte offset into
pname:sequencesIndexBuffer where the index values start.

0 comments on commit b557dd2

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