Contributing Guidelines

The purpose of these guidelines is to explain how to properly contribute to the development process of DXVK-GPLALL project.

Bug Report

If you wish to report an issue that occurs with DXVK-GPLALL, but does not occur with upstream DXVK/DXVK GPLAsync/DXVK Low Latency, you need to provide:

1. Application Info in which issue occurs: Name, Graphics API, Version, Settings related to the issue.
2. DXVK-GPLALL version and build type.
3. OS, GPU, GPU Driver version, Wine/Proton version (if used).
4. Detailed Info about issue and how to repeatedly reproduce it on your configuration.
5. DXVK-GPLALL log files.

Use upstream DXVK bug report template as a template if possible.

Changes to the source code

If you wish to add or change source code in DXVK-GPLALL project you need to:

1. Create a fork of DXVK-GPLALL repository.
2. Select test branch as a target for your changes. Example: GPLALL-2.7-test branch.
3. Create a pull request with your proposal that targets corresponding test branch in original DXVK-GPLALL repository.
   • If you target master branches or AVX2-AMD64 or SSE4.2-INTEL64 branches, you will be asked to close your pull request and create a new one that targets corresponding test branch. Example: GPLALL-2.7-test branch, GPLALL-2.7-AVX2-AMD64-test branch, GPLALL-2.7-SSE4.2-INTEL64-test branch.
4. If your pull request have been approved and merged, you will have to create a pull requests for AVX2-AMD64-test and SSE4.2-INTEL64-test branches to save proper PRs/commits history.

Common practices

• Be sure to test your changes. If you didn't, please say so in the commit message and the pull request text.

• Write informative commit messages. Use present tense to describe the situation with the patch applied, and past tense for the situation before the change.

• The subject line (the first line in a commit message) must contain a prefix identifying the sub system, followed by a short description what impact this commit has.

• The body of the commit message (everything else after the subject line) must be as informative as possible and contain everything that isn't obvious. Don't hesitate to dump as much information as you can - it doesn't cost you anything. Put some effort into it. If someone finds a bug months or years later, and finds that it's caused by your commit (even though your commit was supposed to fix another bug), it would be bad if there wasn't enough information to test the original bug. The old bug might be reintroduced while fixing the new bug.

• Follow git good practices, and split independent changes into several commits. It's usually OK to put them into a single pull request.

• Try to separate cosmetic and functional changes. It's ok to make a few additional cosmetic changes in the same file you're working on. But don't do something like reformatting a whole file, and hiding an actual functional change in the same commit.

• Splitting changes does not mean that you should make them as fine-grained as possible. Commits should form logical steps in development. The way you split changes is important for code review and analyzing bugs.