yum-mirror/slang
Making it easier to work with shaders
git clone https://git.yummers.dev/yum-mirror/slang
368ddbb7b
master
Configure CMake and Build
Slang is already built in debug configuration, so you should be able to run targets
like slangc, slang-test, slangi etc. right away.
If you made some changes and need to rebuild Slang, follow these steps:
- Configure cmake with
cmake --preset default. - Run
cmake --workflow --preset debugto build.
Detailed build instructions can be found in docs/building.md
Formatting
DO THIS BEFORE COMMITING YOUR CHANGES:
RUN ./extras/formatting.sh to format your changes first!!
Your PR needs to be formatted according to our coding style.
Labeling your PR
All PRs needs to be labeled as either "pr: non-breaking" or "pr: breaking". Add the "pr: breaking" label to your PR if you are introducing public API changes that breaks ABI compabibility, or you are introducing changes to the Slang language that will cause the compiler to error out on existing Slang code. It is rare for a PR to be a breaking change.
Debugging
If you encounter a bug related to a problematic instruction, it is often useful to trace the location where the instruction is created.
You can use the extras/insttrace.py script to do this. For example, during debugging you find that an instruction with _debugUID=1234
is wrong, you can run the following command to trace the callstack where the instruction is created:
# From workspace root: python3 ./extras/insttrace.py 1234 ./build/Debug/bin/slangc tests/my-test.slang-target spirv
Testing
Your PR should include a regression test for the bug you are fixing.
Normally, these tests present as a .slang file under tests/ directory.
You will need to run your test with slang-test tests/path/to/your-new-test.slang.
You will need to build the slang-test target first.
Note that your execution environment does not have a GPU, so you can't run any tests that requires a GPU locally, for example,
you won't be able to run a shader test using D3D12, Vulkan, Metal or WGSL.
If the changes you are making is not specific to a particular GPU target, you can craft your test case to run on the CPU by writing the following as the first line of your test shader:
//TEST:COMPARE_COMPUTE(filecheck-buffer=CHECK):-output-using-type -cpu
See tests/language-feature/lambda/lambda-0.slang for a full example.
Or you can craft your test to run with slangi (byte-code interpreter), such as:
//TEST:INTERPRET(filecheck=CHECK):
void main()
{
//CHECK: hello!
printf("hello!");
}
If you are working on a GPU specific feature, don't try to run the test locally, just leave your PR to the CI for verification.
1## Configure CMake and Build 2 3Slang is already built in debug configuration, so you should be able to run targets 4like `slangc`, `slang-test`, `slangi` etc. right away. 5 6If you made some changes and need to rebuild Slang, follow these steps: 7 81. Configure cmake with `cmake --preset default`. 92. Run `cmake --workflow --preset debug` to build. 10 11Detailed build instructions can be found in docs/building.md 12 13## Formatting 14 15DO THIS BEFORE COMMITING YOUR CHANGES: 16RUN `./extras/formatting.sh` to format your changes first!! 17Your PR needs to be formatted according to our coding style. 18 19## Labeling your PR 20 21All PRs needs to be labeled as either "pr: non-breaking" or "pr: breaking". 22Add the "pr: breaking" label to your PR if you are introducing public API changes that breaks ABI compabibility, 23or you are introducing changes to the Slang language that will cause the compiler to error out on existing Slang code. 24It is rare for a PR to be a breaking change. 25 26## Debugging 27 28If you encounter a bug related to a problematic instruction, it is often useful to trace the location where the instruction is created. 29You can use the `extras/insttrace.py` script to do this. For example, during debugging you find that an instruction with `_debugUID=1234` 30is wrong, you can run the following command to trace the callstack where the instruction is created: 31 32``` bash 33# From workspace root: 34python3 ./extras/insttrace.py 1234 ./build/Debug/bin/slangc tests/my-test.slang -target spirv 35``` 36 37## Testing 38 39Your PR should include a regression test for the bug you are fixing. 40Normally, these tests present as a `.slang` file under `tests/` directory. 41You will need to run your test with `slang-test tests/path/to/your-new-test.slang`. 42You will need to build the `slang-test` target first. 43Note that your execution environment does not have a GPU, so you can't run any tests that requires a GPU locally, for example, 44you won't be able to run a shader test using D3D12, Vulkan, Metal or WGSL. 45 46If the changes you are making is not specific to a particular GPU target, you can craft your test case to run on the CPU 47by writing the following as the first line of your test shader: 48 49``` 50//TEST:COMPARE_COMPUTE(filecheck-buffer=CHECK):-output-using-type -cpu 51``` 52See `tests/language-feature/lambda/lambda-0.slang` for a full example. 53 54Or you can craft your test to run with `slangi` (byte-code interpreter), such as: 55 56``` 57//TEST:INTERPRET(filecheck=CHECK): 58void main() 59{ 60//CHECK: hello! 61printf("hello!"); 62} 63``` 64 65If you are working on a GPU specific feature, don't try to run the test locally, just leave your PR to the CI for verification.