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: docs/autodiff-tips-custom-diffs.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,7 +107,7 @@ One of the key strengths of Slang's autodiff system is its flexibility. You are
107
107
108
108
This means you can address just the parts of your function stack that truly need custom derivatives (e.g., the opaque or numerically unstable sections) while still leveraging Slang's powerful autodiff for the rest of your computations. This hybrid approach offers the best of both worlds: the convenience and efficiency of automatic differentiation where it's most effective, and the precision and control of custom derivatives where they are absolutely necessary.
109
109
110
-
For examples of this in practice, take a look at some of the [experiments]() in our SlangPy samples repository. In particular, you can see a user-defined custom derivative function invoking bwd\_diff() to make use of automatic differentiation for the functions it calls out to in the [differentiable splatting experiment](https://github.com/shader-slang/slangpy-samples/blob/main/experiments/diff-splatting/diffsplatting2d.slang#L512).
110
+
For examples of this in practice, take a look at some of the [experiments](https://github.com/shader-slang/slangpy-samples/blob/main/experiments) in our SlangPy samples repository. In particular, you can see a user-defined custom derivative function invoking bwd\_diff() to make use of automatic differentiation for the functions it calls out to in the [differentiable splatting experiment](https://github.com/shader-slang/slangpy-samples/blob/main/experiments/diff-splatting/diffsplatting2d.slang#L512).
111
111
112
112
# Approximating Derivatives for Inherently Undifferentiable Functions
The main header file is `slang.h`, though you also need `slang-com-ptr.h` to have the definition of Slang::ComPtr used throughout the API. `slang-com-helper.h` is nice to have, since it provides helpers for checking API return values and otherwise using COM.
44
44
```cpp
45
45
#include"slang.h"
46
46
#include"slang-com-ptr.h"
47
47
#include"slang-com-helper.h"
48
48
```
49
49
50
-
####Create Global Session
50
+
### Create Global Session
51
51
The global API call to `createGlobalSession` is always going to be the first runtime step, since it establishes a connection to the Slang API implementation.
To read more about what sessions are all about, see [About Sessions](#about-sessions).
60
60
Creating a session sets the configuration for what you are going to do with the API.
61
61
@@ -69,7 +69,7 @@ The `SessionDesc` object holds all the configuration for the Session.
69
69
slang::SessionDesc sessionDesc = {};
70
70
```
71
71
72
-
#####List of enabled compilation targets
72
+
#### List of enabled compilation targets
73
73
74
74
Here, only one target is enabled, `spirv_1_5`. You can enable more targets, for example, if you need to be able to compile the same source to DXIL as well as SPIRV.
75
75
```cpp
@@ -81,7 +81,7 @@ Here, only one target is enabled, `spirv_1_5`. You can enable more targets, for
81
81
sessionDesc.targetCount = 1;
82
82
```
83
83
84
-
##### Preprocessor defines
84
+
#### Preprocessor defines
85
85
86
86
Slang supports using the preprocessor.
87
87
```cpp
@@ -94,7 +94,7 @@ Slang supports using the preprocessor.
Here is where you can specify Session-wide options. Check the [User Guide](https://docs.shader-slang.org/en/latest/external/slang/docs/user-guide/08-compiling.html#compiler-options) for info on available options.
100
100
@@ -110,7 +110,7 @@ Here is where you can specify Session-wide options. Check the [User Guide](https
Modules are the granularity of shader source code that can be compiled in Slang. When using the compilation API, there are two main functions to consider.
125
125
@@ -142,11 +142,11 @@ Modules are the granularity of shader source code that can be compiled in Slang.
142
142
}
143
143
```
144
144
145
-
##### Life Time of Modules
145
+
#### Life Time of Modules
146
146
147
147
Modules are owned by the slang Session. Once loaded, they are valid as long as the Session is valid.
148
148
149
-
#### Query Entry Points
149
+
### Query Entry Points
150
150
151
151
Slang shaders may contain many entry points, and it's necessary to be able to identify them programatically in the Compilation API in order to select which entry points to compile.
152
152
@@ -170,7 +170,7 @@ A common way to query an entry-point is by using the `IModule::findEntryPointByN
170
170
It is also possible to query entry-points by index, and work backwards to check the name of the entry-points that are returned at different indices.
171
171
Check the [User Guide](https://docs.shader-slang.org/en/latest/external/slang/docs/user-guide/09-reflection.html#program-reflection) for info.
172
172
173
-
####Compose Modules and Entry Points
173
+
### Compose Modules and Entry Points
174
174
175
175
Up to this point, modules have been loaded, and entry points have been identified, but to move forward with defining a GPU program, the relevant subset need to be selected for _composition_ into a unified program.
176
176
@@ -194,7 +194,7 @@ Up to this point, modules have been loaded, and entry points have been identifie
194
194
}
195
195
```
196
196
197
-
#### Link
197
+
### Link
198
198
199
199
Ensure that there are no missing dependencies in the composed program by using `link()`.
200
200
@@ -210,7 +210,7 @@ Ensure that there are no missing dependencies in the composed program by using `
210
210
}
211
211
```
212
212
213
-
####Get Target Kernel Code
213
+
### Get Target Kernel Code
214
214
215
215
Finally, it's time to compile the linked Slang program to the target format.
216
216
@@ -266,7 +266,7 @@ Both methods cache results within the session and will return a pre-compiled blo
266
266
About Sessions
267
267
--------------
268
268
269
-
####What's a session?
269
+
### What's a session?
270
270
271
271
A session is a scope for caching and reuse. As you use the Slang API, the session caches everything that is loaded in it.
272
272
@@ -278,7 +278,7 @@ It's strongly recommended to use as few session objects as possible in applicati
278
278
279
279
Using long-lived sessions with Slang API is a big advantage over compiling with the standalone `slangc` compiler executable, since each invocation of `slangc` creates a new session object by necessity.
280
280
281
-
####When do I need a new Session?
281
+
### When do I need a new Session?
282
282
283
283
A session does have some global state in it which currently makes it unable to cache and reuse artifacts, namely, the `#define` configurations. Unique combinations of preprocessor `#defines` used in your shaders will require unique session objects.
284
284
@@ -296,16 +296,16 @@ API methods for module precompilation are described in the [User Guide](https://
296
296
Specialization
297
297
--------------
298
298
299
-
####Link-time Constants
299
+
### Link-time Constants
300
300
301
301
This form of specialization involves placing relevant constant definitions in a separate Module that can be selectively included. For example, if you have two variants of a shader that differ in constants that they use, you can create two different Modules for the constants, one for each variant. When composing one variant or the other, just select the right constants module in createCompositeComponentType(). This is described also in the [User Guide](https://docs.shader-slang.org/en/latest/external/slang/docs/user-guide/10-link-time-specialization.html#link-time-constants)
302
302
303
-
####Link-time Types
303
+
### Link-time Types
304
304
305
305
Similar to Link-time Constants. This form of specialization simply puts different versions of user types in separate modules so that the needed implementation can be selected when creating the CompositeComponentType.
Say you have a shader that has a feature in it that can be in one of two states, "High Quality" and "Low Quality". One way to support both modes of operation is to use generics. Put the logic for the two modes into two structs, both conforming to an interface (e.g. `IQuality`) that can be consistently used by callers.
Notice in particular the switch case added in the function `float U_S11specialized8IQuality8getValuep0pf_0(uint2 _S1)`.
571
571
572
-
####Supporting both specialization and dynamic dispatch
572
+
### Supporting both specialization and dynamic dispatch
573
573
574
574
In the prior example, `HighQuality` and `LowQuality` are both supported in a single uber-shader, compiled to support dynamic dispatch on the call to `getValue()`. To achieve this, two `ITypeConformance` objects were added to the composite component.
575
575
@@ -813,7 +813,7 @@ int main()
813
813
}
814
814
```
815
815
816
-
####Compile it (g++ directions)
816
+
### Compile it (g++ directions)
817
817
* Assumes Slang is installed in the current directory at `slang`.
818
818
* Assumes program is saved to "shortest.cpp".
819
819
* Assumes a release build of Slang.
@@ -824,7 +824,7 @@ If any of the above assumptions are wrong in your case, adjust the paths below t
0 commit comments