This makes the VulkanTools and VulkanSamples easier to work with and avoids compatibility issues
that might arise with Vulkan-LoaderAndValidationLayers components if they were obtained from a separate repository.
-### **We Do Need Your Help**
+### **The Vulkan Ecosystem Needs Your Help**
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,
Please see the [section about Validation Layers](#special-considerations-for-validation-layers)
later on this page.
+Repository Issue labels:
+
+* _Incomplete_: These issues refer to missing validation checks that users have encountered during application development that would have been directly useful, and are high priority.
+* _Enhancement_: These issues refer to ideas for extending or improving the loader, demos, or validation layers.
+* _Bug_: These issues refer to invalid or broken functionality and are the highest priority.
+
+If you choose to work on an issue that is already assigned, simply coordinate with the current assignee.
+
### **How to Submit Fixes**
* **Ensure that the bug was not already reported or fixed** by searching on GitHub under Issues
creating a branch with your commits, and then [submitting a pull request](https://help.github.com/articles/using-pull-requests/).
* Please base your fixes on the master branch. SDK branches are generally not updated except for critical fixes needed to repair an SDK release.
* Please include the GitHub Issue number near the beginning of the commit text if applicable.
- * Example: "GitHub 123: Fix missing init"
+ * Example: "layers: GH123, Fix missing init"
* If your changes are restricted only to files from the Vulkan-LoaderAndValidationLayers repository, please direct your pull request to that repository, instead of VulkanTools or VulkanSamples.
#### **Coding Conventions and Formatting**
-* Use the [Google style guide](https://google.github.io/styleguide/cppguide.html) for source code with the following two exceptions.
+* Use the **[Google style guide](https://google.github.io/styleguide/cppguide.html)** for source code with the following exceptions:
* The column limit is 132 (as opposed to the default value 80). The clang-format tool will handle this. See below.
* The indent is 4 spaces instead of the default 2 spaces. Again, the clang-format tool will handle this.
- * If you can justify a reason for violating a rule in the guidelines, then you are free to do so. Be prepared to defend your decision during code review. This should be used responsibly. An example of a bad reason is “I don’t like that rule.” An example of a good reason is “This violates the style guide, but it improves type safety.”
+ * If you can justify a reason for violating a rule in the guidelines, then you are free to do so. Be prepared to defend your decision during code review. This should be used responsibly. An example of a bad reason is "I don't like that rule." An example of a good reason is "This violates the style guide, but it improves type safety."
-* Run clang-format on your changes to maintain formatting.
+* Run **clang-format** on your changes to maintain formatting
* There are `.clang-format files` throughout the repository to define clang-format settings
which are found and used automatically by clang-format.
* A sample git workflow may look like:
> $ git add -u .
> $ git commit
-* Follow these seven rules for git commit messages.
+* **Format your git commit messages** consistently with the repo
* Limit the subject line to 50 characters. Begin with a one-word component description followed by a colon (e.g. loader, layers, tests, etc.).
* Separate subject from body with a blank line.
* Wrap the body at 72 characters.
* Use the body to explain what and why vs. how.
* Use the imperative mood in the subject line. This just means to write it as a command (e.g. Fix the sprocket).
-#### **Testing**
-* Run the existing tests in the repository before and after your changes to check for any regressions.
+#### **Testing Your Changes**
+* Run the existing tests in the repository before and after each if your commits to check for any regressions.
There are some tests that appear in all repositories.
These tests can be found in the following folders inside of your target build directory:
+
(These instructions are for Linux)
* In the `demos` directory, run:
> run_all_tests.sh
+* On Windows, a quick sanity check can be run from inside Visual Studio -- just run the `vk_layer_validation_tests` project, or you can run `run_all_tests.ps1` from a PowerShell window
+
* Note that some tests may fail with known issues or driver-specific problems.
The idea here is that your changes shouldn't change the test results, unless that was the intent of your changes.
* Run tests that explicitly exercise your changes.
And finally, the test should check that the validation error report is generated and consider the test as "passing"
if the report is received. Otherwise, the test should indicate "failure".
This new test should be added to the validation layer test program in the `tests` directory and contributed
-at the same time as the new validation check itself.
+at the same time as the new validation check itself, along with appropriate updates to `layers\vk_validation_error_database.txt`.
There are many existing validation tests in this directory that can be used as a starting point.
projects / platform / upstream / Vulkan-Tools.git / commitdiff