-
Notifications
You must be signed in to change notification settings - Fork 1
Contributing
See Adding Tests page for technical details on how to implement new test cases.
In addition to main
branch, VK-GL-CTS repository hosts several API-specific release branches. They follow the convention of <CTS name>.<API major>.<API minor>.<CTS major>
where <CTS name>
is one of:
- Vulkan CTS:
vulkan-cts
- OpenGL CTS:
opengl-cts
- OpenGL ES CTS:
opengl-es-cts
If you are contributing new tests or other improvements, they must always target main
branch. Bug fixes on the other hand must be targeted to the earliest release branch where the bug occurs.
dEQP is written in "traditional" C++ 98/03. Use of C++11 or newer is not currently allowed.
dEQP coding conventions are described in framework/delibs/coding_guidelines/de-coding-guidelines.html
See code under framework/delibs/decpp
for more examples on desired style.
Pull requests for new tests or features should target main
, and bug fixes should target the release branch where the bug was first introduced in (for example vulkan-cts-1.0.1
for a bug in test that was added in Vulkan CTS 1.0.1).
To keep git history meaningful, merge requests should generally contain just one, or a few atomic commits, meaning that all intermediate steps build & function correctly. When you need to update an existing pull request (to address feedback for example), please do so by modifying the existing commit(s) rather than adding additional commits on top.
To update one commit pull request, you can do:
git checkout <pull request branch>
# edit files
git add <modified files>
git commit --amend
git push --force origin <merge request branch>
--amend
flag modifies topmost commit instead of creating a new one.
See Testing New Tests for documentation how any new test code should be tested.
In addition, dEQP has self-test module under modules/internal
. Any framework changes should be tested by running internal tests. For any new framework features appropriate tests should be added as well.