You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+23-1Lines changed: 23 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,10 +40,32 @@ Before submitting a feature or substantial code contribution please discuss it w
40
40
41
41
### Coding guidelines
42
42
43
-
The coding, style, and general engineering guidelines follow those described in the docs/CodingStandards.rst. For additional guidelines in code specific to HLSL, see the docs/HLSLChanges.rst file.
43
+
The coding, style, and general engineering guidelines follow those described in the [LLVM Coding Standards](docs/CodingStandards.rst). For additional guidelines in code specific to HLSL, see the [HLSL Changes](docs/HLSLChanges.rst) docs.
44
44
45
45
DXC has adopted a clang-format requirement for all incoming changes to C and C++ files. PRs to DXC should have the *changed code* clang formatted to the LLVM style, and leave the remaining portions of the file unchanged. This can be done using the `git-clang-format` tool or IDE driven workflows. A GitHub action will run on all PRs to validate that the change is properly formatted.
46
46
47
+
#### Applying LLVM Standards
48
+
49
+
All new code contributed to DXC should follow the LLVM coding standards.
50
+
51
+
Note that the LLVM Coding Standards have a golden rule:
52
+
53
+
> **If you are extending, enhancing, or bug fixing already implemented code, use the style that is already being used so that the source is uniform and easy to follow.**
54
+
55
+
The golden rule should continue to be applied to places where DXC is self-consistent. A good example is DXC's common use of `PascalCase` instead of `camelCase` for APIs in some parts of the HLSL implementation. In any place where DXC is not self-consistent new code should follow the LLVM Coding Standard.
56
+
57
+
A good secondary rule to follow is:
58
+
59
+
> **When in doubt, follow LLVM.**
60
+
61
+
Adopting LLVM's coding standards provides a consistent set of rules and guidelines to hold all contributions to. This allows patch authors to clearly understand the expectations placed on contributions, and allows reviewers to have a bar to measure contributions against. Aligning with LLVM by default ensures the path of least resistance for everyone.
62
+
63
+
Since many of the LLVM Coding Standards are not enforced automatically we rely on code reviews to provide feedback and ensure contributions align with the expected coding standards. Since we rely on reviewers for enforcement and humans make mistakes, please keep in mind:
64
+
65
+
> **Code review is a conversation.**
66
+
67
+
It is completely reasonable for a patch author to question feedback and provide additional context about why something was done the way it was. Reviewers often see narrow slices in diffs rather than the full context of a file or part of the compiler, so they may not always provide perfect feedback. This is especially true with the application of the "golden rule" since it depends on understanding a wider context.
68
+
47
69
### Documenting Pull Requests
48
70
49
71
Pull request descriptions should have the following format:
Copy file name to clipboardExpand all lines: docs/DXIL.rst
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -225,10 +225,10 @@ DXIL uses 32-bit pointers in its representation.
225
225
Out-of-bounds behavior
226
226
----------------------
227
227
228
-
Indexable thread-local accesses are done via LLVM pointer and have C-like OOB semantics.
229
-
Groupshared accesses are done via LLVM pointer too. The origin of a groupshared pointer must be a single TGSM allocation.
230
-
If a groupshared pointer uses in-bound GEP instruction, it should not OOB. The behavior for an OOB access for in-bound pointer is undefined.
231
-
For groupshared pointer from regular GEP, OOB will has same behavior as DXBC. Loads return 0 for OOB accesses; OOB stores are silently dropped.
228
+
Indexable thread-local accesses are done via LLVM pointers and have C-like OOB semantics.
229
+
Groupshared accesses are done via LLVM pointers too. The origin of a groupshared pointer must be a single TGSM allocation.
230
+
If a groupshared pointer uses an in-bound GEP instruction, it should not OOB. The behavior for an OOB access for in-bound pointer is undefined.
231
+
For a groupshared pointer from regular GEP, OOB will have the same behavior as DXBC. Loads return 0 for OOB accesses; OOB stores are silently dropped.
232
232
233
233
Resource accesses keeps the same out-of-bounds behavior as DXBC. Loads return 0 for OOB accesses; OOB stores are silently dropped.
234
234
@@ -3294,9 +3294,9 @@ Modules and Linking
3294
3294
===================
3295
3295
3296
3296
HLSL has linking capabilities to enable third-party libraries. The linking step happens before shader DXIL is given to the driver compilers.
3297
-
Experimental library generation is added in DXIL1.1. A library could be created by compile with lib_6_1 profile.
3298
-
A library is a dxil container like the compile result of other shader profiles. The difference is library will keep information for linking like resource link info and entry function signatures.
3299
-
Library support is not part of DXIL spec. Only requirement is linked shader must be valid DXIL.
3297
+
Experimental library generation is added in DXIL1.1. A library could be created by compiling with the lib_6_1 profile.
3298
+
A library is a dxil container like the compile result of other shader profiles. The difference is a library will keep information for linking like resource link info and entry function signatures.
3299
+
Library support is not part of the DXIL spec. The only requirement is that the linked shader must be valid DXIL.
0 commit comments