commit | 1e25e5ada6b947c4e99bcf9a3c544dd7cb44660b | [log] [tgz] |
---|---|---|
author | Nicolas Capens <capn@google.com> | Fri Nov 18 14:06:44 2022 +0000 |
committer | Nicolas Capens <capn@google.com> | Fri Nov 18 14:06:44 2022 +0000 |
tree | 3281a6512c0595ccaa32c71517eca0258741c17b | |
parent | 74fe456ddd8e1997be2dd268b4b78ad05b1dbcae [diff] |
Squashed 'third_party/SPIRV-Headers/' changes from 0bcc62492..c214f6f2d c214f6f2d Merge pull request #300 from alelenv/reorder 879bcd7a3 Merge pull request #298 from MrSidims/update_intel_extensions e2f6e9ad6 Remove unnecessary extensions addition 4c490b2cc Remove extension 2a7559a1f Fix typo. b582430a4 Review feedback 1. 47f2465ee Revert "Merge pull request #301 from alan-baker/hpp1" (#302) 747031e10 Merge pull request #301 from alan-baker/hpp1 8a13c6ded Add spirv.hpp11 to BUILD.gn e0d5cf053 Add headers for SPV_NV_shader_invocation_reorder. 23d4c8e5e Add SPV_INTEL_runtime_aligned 48d4b677a Add SPV_INTEL_fpga_dsp_control b3e7b5137 Add SPV_INTEL_fpga_invocation_pipelining_attributes 62269acdb Update SPV_INTEL_fpga_loop_controls to rev I 85a1ed200 Merge pull request #294 from kpet/clspv-texel-buffer 9cae924e9 Merge pull request #295 from KhronosGroup/fix_omm ef8bbc58d Fix extension for RayTracingOpacityMicromapEXT 000c5f0fa Merge pull request #293 from Hugobros3/master 0a05fafad Merge pull request #292 from ewerness-nv/extmicromapgithub 4b5d12864 Add support for texel buffers to clspv non-semantic instruction set 68795e42a registered ID for Shady d2b45422b VK_EXT_opacity_micromap 4bd8fc0c8 Merge pull request #289 from kpet/spv-arm-core-builtins 56740d094 Add definitions for SPV_ARM_core_builtins 87d5b782b Merge pull request #288 from pmistryNV/GL_EXT_mesh_shader_github 80cfd2909 Implement headers definitions for SPV_EXT_mesh_shader. 93754d52d Merge pull request #285 from jeremy-lunarg/hayes-fix-271 539b23984 Remove custom target if skipping install git-subtree-dir: third_party/SPIRV-Headers git-subtree-split: c214f6f2d1a7253bb0e9f195c2dc5b0659dc99ef Change-Id: Ic579f3c4b40b7ed099d1000388cef0a4c95b870b
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 and install 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.) Here's a complete example:
cd tools/buildHeaders mkdir build cd build cmake .. cmake --build . --target install cd .. ./bin/makeHeaders
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.