The source code for The Vulkan-ValidationLayer components is sponsored by Khronos and LunarG.
The Vulkan validation layers are one of the larger and more important components in this repository. While there are often active and organized development efforts underway to improve their coverage, there are always opportunities for anyone to help by contributing additional validation layer checks and tests for these validation checks.
There are a couple of methods to identify areas of need:
vk_validation_stats.pyscript (in the scripts directory) with the
-todocommand line argument to see a list of as-yet unimplemented validation checks.
vk_validation_stats.py(available in text, html, or csv format) to identify related checks that may be implemented simultaneously.
Of course, if you have your own work in mind, please open an issue to describe it and assign it to yourself. Finally, please feel free to contact any of the developers that are actively contributing should you wish to coordinate further. Please see the section about Validation Layers later on this page.
Repository Issue labels:
It is the maintainers goal for all issues to be assigned or triaged within one business day of their submission. If you choose to work on an issue that is assigned, simply coordinate with the current assignee.
Use the Google style guide for source code with the following exceptions:
public:) is indented 2 spaces instead of the default 1 space. Again, the clang-format tool will handle this.
*.cppinstead of the default
Run clang-format on your changes to maintain consistent formatting
.clang-formatfiles present in the repository to define clang-format settings which are found and used automatically by clang-format.
# Make changes to the source. $ git add -u . $ git clang-format --style=file # Check to see if clang-format made any changes and if they are OK. $ git add -u . $ git commit
Strive for commits that implement a single or related set of functionality, using as many commits as is necessary (more is better). That said, please ensure that the repository compiles and passes tests without error for each commit in your pull request. Note that to be accepted into the repository, the pull request must [pass all tests](#testing your changes) on all supported platforms -- the automatic Github Travis and AppVeyor continuous integration features will assist in enforcing this requirement.
Run the included layer validation tests (vk_layer_validation_tests) in the repository before and after each of your commits to check for any regressions.
Write additional layer validation tests that explicitly exercise your changes.
Feel free to subject your code changes to other tests as well!
Pull Requests to GitHub are tested in the cloud on Linux and Windows VMs. The Linux VMs use Travis CI with the sequence of commands driven by the .travis.yml file. The Windows VMs use AppVeyor with the sequence of commands driven by the .appveyor.yml file.
The Linux testing includes iterating on all of the validation layer tests over multiple different device profiles using the devsim layer in combination with the mock icd. This is a fast way to simulate testing across different devices. Any new tests must pass across all device profiles.
testsdirectory and contributed at the same time as the new validation check itself. There are many existing validation tests in this directory that can be used as a starting point.
vk_validation_stats.pyscript (in the scripts directory) inspects the layer and test source files and reports a variety of statistics on validation completeness and correctness. Before submitting a change you should run this script with the consistency check (
-c) argument to ensure that your changes have not introduced any inconsistencies in the code.
layers/generateddirectory contains source code that is created by several generator scripts in the
scriptsdirectory. All changes to these scripts must be submitted with the corresponding generated output to keep the repository self-consistent. This requirement is enforced by both Travis CI and AppVeyor test configurations. Regenerate source files after modifying any of the generator scripts and before building and testing your changes. More details can be found in BUILD.md.
cmake-format.pyfile in the repository to define the settings. See the cmake-format page for information about its simple markup for comments.
# ~~~comment line before and after that block.
# cmake-format: offand
# cmake-format: oncomment lines.
sudo pip install cmake_format
cmake-format --in-place $FILENAME
sed --in-place='' 's/^ *#/#/' $FILENAME
You will be prompted with a one-time “click-through” CLA dialog as part of submitting your pull request or other contribution to GitHub.
All contributions made to the Vulkan-ValidationLayers repository are Khronos branded and as such, any new files need to have the Khronos license (Apache 2.0 style) and copyright included. Please see an existing file in this repository for an example.
All contributions made to the LunarG repositories are to be made under the Apache 2.0 license and any new files need to include this license and any applicable copyrights.
You can include your individual copyright after any existing copyrights.