status-im
/
Vulkan-Docs
mirror of https://github.com/status-im/Vulkan-Docs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
Vulkan-Docs/COPYING.md

33 lines
1.8 KiB
Markdown
Raw Normal View History

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: * 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).
2016-09-24 07:58:11 +00:00
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.