* Use bazel 5 for Linux bazel builds.
* Download bazel 5.0.0 for macos and windows bazel builds.
* Modify the readme to mention bazel 5.0.0 as the version to use.
spirv-diff is a new tool that produces diff-style output comparing two
SPIR-V modules. The instructions between the src and dst modules are
matched as best as the tool can, and output is produced (in src
id-space) that shows which instructions are removed in src, added in dst
or modified between them. The order of instructions are not retained.
Matching instructions between two SPIR-V modules is not trivial, and
thus a number of heuristics are applied in this tool. In particular,
without debug information, it's hard to match functions as they can be
reordered. As such, this tool is primarily useful to produce the diff
of two SPIR-V modules derived from the same source.
This tool can be useful in a number of scenarios:
- Compare the SPIR-V before and after modifying a shader
- Compare the SPIR-V produced from a shader before and after compiler
codegen changes.
- Compare the SPIR-V produced from a shader before and after some
transformation or optimization.
- Compare the SPIR-V produced from a shader with different compilers.
- Mention that `depot_tools` are required and link to that repo.
- Make `roll_deps.sh` exit on error. The script passes `shellcheck`
with this change.
- Reword instruction in the README.
- Remove Appveyor CI
- Write new "Getting the source" subsection, consolidating material
from a couple of places. Emphasize using the utils/git-sync-deps
script for getting a known-good combination of sources.
- Built artifacts:
- top of tree artifacts are from Kokoro CI bots
- mention Vulkan SDK and Android NDK as alternatives
Fixes: #4577
This change improves spirv-fuzz CMake code to be more compatible with other projects that might want to include spirv-fuzz as a sub-project.
* Add a CMake option for building spirv-fuzz.
* We now check if protobuf targets are already available.
* We no longer specify `-DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_USE_UNALIGNED=0`; a newer version of protobuf does not require this. Note that we probably should have specified this for protobuf targets as well, but this is no longer needed.
* Updated protobuf version in Kokoro scripts and README.md.
This adds in a script for updating DEPS and another for pulling in the
specified versions in the DEPS file.
DEPS entries that are not part of the documented build processs are
removed. Using the documented cmake process with them made for a very
sad state of one's checkout. If this removal breaks workflows we can
revist this, since the state is saved in git.
DEPS are rolled forward, so that this is taking use to a known good
state. These look like scary big rolls, but in reality the bots and
most people are running near HEAD for external/, so this integration
should already have been tested.
Summary of DEPS roll:
+ Rolling 3 dependencies
+ Roll external/effcee/ 04b624799..b83b58d17 (14 commits)
+ Roll external/googletest/ 98a0d007d..2f42d769a (576 commits)
+ Roll external/re2/ 6cf8ccd82..848dfb7e1 (90 commits)
+ Created with:
+ roll-dep external/effcee external/googletest external/re2 external/spirv-headers
Fixes#2665
Updated script to work with python3 and python2.
Added required tools.
We added a section to the readme to mention the tools that are needed to
build and test spirv-tools. For the compiler, the compilers used by the
bots are mentioned.
The bots have been changed. The windows bots will not use python 3.6 for testing. The other bots will still use python 2.7. Both Python2 and Python3 will be tested.
Fixes#2407.
Fixes#1856.
There was some confusion about the SPIRV_WERROR option when it is turned
off. When the option is off nothing is done. That is, we do not add
-Wno-error. This means that if the parent project added -Werorr to the
C flags or CXX flags, then warnings will still be treated as errors.
I've updated the README.md to make this explicit.
Fixes#2121.
Add Effcee as an optional dependency for use in tests. In future it will
be a required dependency.
Effcee is a stateful pattern matcher that has much of the functionality
of LLVM's FileCheck, except in library form. Effcee makes it much easier
to write tests for optimization passes.
Demonstrate its use in a test for the strength-reduction pass.
Update README.md with example commands of how to get sources.
Update Appveyor and Travis-CI build rules.
Also: Include test libraries if not SPIRV_SKIP_TESTS
- SPIRV_SKIP_TESTS is implied by SPIRV_SKIP_EXECUTABLES
Add extra iterators for ir::Module's sections
Add extra getters to ir::Function
Add a const version of BasicBlock::GetLabelInst()
Use the max of all inputs' version as version
Split debug in debug1 and debug2
- Debug1 instructions have to be placed before debug2 instructions.
Error out if different addressing or memory models are found
Exit early if no binaries were given
Error out if entry points are redeclared
Implement copy ctors for Function and BasicBlock
- Visual Studio ends up generating copy constructors that call deleted
functions while compiling the linker code, while GCC and clang do not.
So explicitly write those functions to avoid Visual Studio messing up.
Move removing duplicate capabilities to its own pass
Add functions running on all IDs present in an instruction
Remove duplicate SpvOpExtInstImport
Give default options value for link functions
Remove linkage capability if not making a library
Check types before allowing to link
Detect if two types/variables/functions have different decorations
Remove decorations of imported variables/functions and their types
Add a DecorationManager
Add a method for removing all decorations of id
Add methods for removing operands from instructions
Error out if one of the modules has a non-zero schema
Update README.md to talk about the linker
Do not freak out if an imported built-in variable has no export
Update README to describe that we understand SPIR-V syntax based on the
grammar files included from the SPIRV-Headers repo.
(Also, it's high time we issue a v2017 release!
Generate a vim syntax file for SPIR-V assembly.
Copy the resulting spvasm.vim into your $HOME/.vim/syntax directory
to get syntax highlighting in Vim.
Also, suggest that the grammar file include information
about what opcodes can be used in OpSpecConstantOp.
