mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-10 13:26:32 +00:00
95dd2f34c5
* 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).
1.8 KiB
1.8 KiB
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.