commit | 91f0d25711cbd5d2b400f513b0d070ca9d655581 | [log] [tgz] |
---|---|---|
author | Alexis Hetu <sugoi@google.com> | Mon Jul 27 10:59:24 2020 -0400 |
committer | Alexis Hetu <sugoi@google.com> | Mon Jul 27 10:59:24 2020 -0400 |
tree | 7c3e4f6faf3e58b7c5b2c4666394fc1139b4b573 | |
parent | 035acbd2733f3fdcd5ae92e6267ecfb5060286e4 [diff] |
Squashed 'third_party/SPIRV-Headers/' changes from f8bf11a02..979924c8b 979924c8b Support SPV_KHR_terminate_invocation (#163) 7f2ae1193 Merge pull request #162 from vkushwaha-nv/SPV_EXT_shader_atomic_float 7083cb52e Add changes for SPV_EXT_shader_atomic_float 308bd0742 Merge pull request #160 from dj2/reg_tint 5ce353315 Register the Tint compiler 11d7637e7 Merge pull request #159 from dneto0/fix-quotes 291d7bf7a spir-v.xml: Use plain ASCII quotes in comment ed09fc149 Merge pull request #158 from mkinsner/mkinsner/fpfastmath_allocation_mechanism f2d2ca132 Rebuild headers against the previous grammar commit. 9e2b21a74 Merge pull request #150 from MrSidims/private/MrSidims/UpstreamIntelExt 7d343e9c0 Apply suggestions dfa87b6d4 Add Intel specific definitions from KhronosGroup/SPIRV-LLVM-Translator ae6e15156 Header build from previous grammar update. 8012d1c86 Merge pull request #152 from MrSidims/private/MrSidims/FunctionPointers 982a08f59 Propose bit allocation mechanism for the FP Fast Math Mode bitfield, following from the mechanism previously added for the loop control bitfield. ac638f181 Merge pull request #157 from dneto0/update-example 1fa1a92e0 Update example to use unified1 headers c0df742ec Update headers to SPIR-V 1.5 Revision 3 375789625 Add a bunch of missing "version" : "None" for ray tracing. 6300597a6 Rebuild the headers with the fixed grammar file. c26f7e838 Add missing "version" : "None" for ShaderCallKHR 445017dc7 Grammar: The ray-tracing updates were not done in numerical ordering. 2ad0492fb Discuss generator magic number reservations. 9995e294c Add SPV_INTEL_function_pointers preview extension git-subtree-dir: third_party/SPIRV-Headers git-subtree-split: 979924c8bc839e4cb1b69d03d48398551f369ce7
This repository contains machine-readable files for the SPIR-V Registry. This includes:
Headers are provided in the include directory, with up-to-date headers in the unified1
subdirectory. Older headers are provided according to their version.
In contrast, the XML registry file has a linear history, so it is not tied to SPIR-V specification versions.
When a new version or revision of the SPIR-V specification is published, the SPIR-V Working Group will push new commits onto master, updating the files under include.
The SPIR-V XML registry file is updated by Khronos whenever a new enum range is allocated.
Pull requests can be made to
Tools that generate SPIR-V should use a magic number in the SPIR-V to help identify the generator.
Care should be taken to follow existing precedent in populating the details of reserved tokens. This includes:
Care should be taken to follow existing precedent in populating the details of reserved tokens. This includes:
"version" : "None"
mkdir build cd build cmake .. cmake --build . --target install
Then, for example, you will have /usr/local/include/spirv/unified1/spirv.h
If you want to install them somewhere else, then use -DCMAKE_INSTALL_PREFIX=/other/path
on the first cmake
command.
A CMake-based project can use the headers without installing, as follows:
add_subdirectory
directive to include this source tree.${SPIRV-Headers_SOURCE_DIR}/include}
in a target_include_directories
directive.#include
directives that explicitly mention the spirv
path component.#include "spirv/unified1/GLSL.std.450.h" #include "spirv/unified1/OpenCL.std.h" #include "spirv/unified1/spirv.hpp"
See also the example subdirectory. But since that example is inside this repostory, it doesn't use and add_subdirectory
directive.
A Bazel-based project can use the headers without installing, as follows:
local_repository
to your WORKSPACE
file. For example, if you place SPIRV-Headers under external/spirv-headers
, then add the following to your WORKSPACE
file:local_repository( name = "spirv_headers", path = "external/spirv-headers", )
deps
attribute of your build target based on your needs:@spirv_headers//:spirv_c_headers @spirv_headers//:spirv_cpp_headers @spirv_headers//:spirv_cpp11_headers
For example:
cc_library( name = "project", srcs = [ # Path to project sources ], hdrs = [ # Path to project headers ], deps = [ "@spirv_tools//:spirv_c_headers", # Other dependencies, ], )
#include
directives that explicitly mention the spirv
path component.#include "spirv/unified1/GLSL.std.450.h" #include "spirv/unified1/OpenCL.std.h" #include "spirv/unified1/spirv.hpp"
This will generally be done by Khronos, for a change to the JSON grammar. However, the project for the tool to do this is included in this repository, and can be used to test a PR, or even to include the results in the PR. This is not required though.
The header-generation project is under the tools/buildHeaders
directory. Use CMake to build the project, in a build
subdirectory (under tools/buildHeaders
). There is then a bash script at bin/makeHeaders
that shows how to use the built header-generator binary to generate the headers from the JSON grammar. (Execute bin/makeHeaders
from the tools/buildHeaders
directory.)
Notes:
The GLSL.std.450.h and OpenCL.std.h extended instruction set headers are maintained manually.
The C/C++ header for each of the other extended instruction sets is generated from the corresponding JSON grammar file. For example, the OpenCLDebugInfo100.h header is generated from the extinst.opencl.debuginfo.100.grammar.json grammar file.
To generate these C/C++ headers, first make sure python3
is in your PATH, then invoke the build script as follows:
cd tools/buildHeaders python3 bin/makeExtinstHeaders.py
How are different versions published?
The multiple versions of the headers have been simplified into a single unified1
view. The JSON grammar has a “version” field saying what version things first showed up in.
How do you handle the evolution of extended instruction sets?
Extended instruction sets evolve asynchronously from the core spec. Right now there is only a single version of both the GLSL and OpenCL headers. So we don't yet have a problematic example to resolve.
Copyright (c) 2015-2018 The Khronos Group Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and/or associated documentation files (the "Materials"), to deal in the Materials without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Materials, and to permit persons to whom the Materials are furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Materials. MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS KHRONOS STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS SPECIFICATIONS AND HEADER INFORMATION ARE LOCATED AT https://www.khronos.org/registry/ THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.