yum-mirror/slang

Making it easier to work with shaders

git clone https://git.yummers.dev/yum-mirror/slang

CopilotAdd utility to trace creation of problematic IRInsts to assist LLM in debugging (#7820)368ddbb7b

master
2.6 KiB65 linesraw

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:

  1. Configure cmake with cmake --preset default.
  2. Run cmake --workflow --preset debug to 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:
16    RUN `./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!
61    printf("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.