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
[Impeller] Add support for specialization constants (III). (flutter#47765)
Reland of flutter/engine#47432
Also includes:
flutter/engine#47617flutter/engine#47637
Fixes the performance on iOS by removing blocking on compilation of shaders. From local testing this has identical before/after numbers. Additional, ensures that we don't unecessarily specialize vertex shaders and notes this restriction in the documentation.
Adds support for Specialization constants to Impeller for our usage in the engine. A motivating example has been added in the impeller markdown docs.
Fixesflutter#136210Fixesflutter#119357
Investigating: flutter#138028
A specialization constant is a named variable that is known to be constant at runtime but not when the shader is authored. These variables are bound to specific values when the shader is compiled on application start up and allow the backend to perform optimizations such as branch elimination and constant folding.
4
+
5
+
Specialization constants have two possible benefits when used in a shader:
6
+
7
+
* Improving performance, by removing branching and conditional code.
8
+
* Code organization/size, by removing the number of shader source files required.
9
+
10
+
These goals are related: The number of shaders can be reduce by adding runtime branching to create more generic shaders. Alternatively, branching can be reduced by adding more specialized shader variants. Specialization constants provide a happy medium where the source files can be combined with branching but done so in a way that has no runtime cost.
11
+
12
+
## Example Usage
13
+
14
+
Consider the case of the "decal" texture sampling mode. This is implement via clamp-to-border with
15
+
a border color set to transparent black. While this functionality is well supported on the Metal and
16
+
Vulkan backends, the GLES backend needs to support devices that do not have this extension. As a
17
+
result, the following code was used to conditionally decal:
18
+
19
+
```glsl
20
+
// Decal sample if necessary.
21
+
vec4 Sample(sampler2D sampler, vec2 coord) {
22
+
#ifdef GLES
23
+
return IPSampleDecal(sampler, coord)
24
+
#else
25
+
return texture(sampler, coord);
26
+
#endif
27
+
}
28
+
```
29
+
30
+
This works great as long as we know that the GLES backend can never do the decal sample mode. This is also "free" as the ifdef branch is evaluated in the compiler. But eventually, we added a runtime check for decal mode as we need to support this on GLES. So the code turned into (approximately) the following:
31
+
32
+
```glsl
33
+
#ifdef GLES
34
+
uniform float supports_decal;
35
+
#endif
36
+
37
+
// Decal sample if necessary.
38
+
vec4 Sample(sampler2D sampler, vec2 coord) {
39
+
#ifdef GLES
40
+
if (supports_decal) {
41
+
return texture(sampler, coord);
42
+
}
43
+
return IPSampleDecal(sampler, coord)
44
+
#else
45
+
return texture(sampler, coord);
46
+
#endif
47
+
}
48
+
```
49
+
50
+
Now we've got decal support, but we've also got new problems:
51
+
52
+
* The code is actually quite messy. We have to track different uniform values depending on the backend.
53
+
* The GLES backend is still paying some cost for branching, even though we "know" that decal is or isn't supported when the shader is compiled.
54
+
55
+
### Specialization constants to the rescue
56
+
57
+
Instead of using a runtime check, we can create a specialization constant that is set when compiling the
58
+
shader. This constant will be `1` if decal is supported and `0` otherwise.
59
+
60
+
```glsl
61
+
layout(constant_id = 0) const int supports_decal = 1;
62
+
63
+
vec4 Sample(sampler2D sampler, vec2 coord) {
64
+
if (supports_decal) {
65
+
return texture(sampler, coord);
66
+
}
67
+
return IPSampleDecal(sampler, coord)
68
+
}
69
+
70
+
```
71
+
72
+
Immediately we realize a number of benefits:
73
+
74
+
* Code is the same across all backends
75
+
* Runtime branching cost is removed as the branch is compiled out.
76
+
77
+
78
+
## Implementation
79
+
80
+
Only 32bit ints are supported as const values and can be used to represent:
81
+
82
+
* true/false via 0/1.
83
+
* function selection, such as advanced blends. The specialization value maps to a specific blend function. For example, 0 maps to screen and 1 to overlay via a giant if/else macro.
84
+
* Only fragment shaders can be specialized. This limitation could be removed with more investment.
85
+
86
+
*AVOID* adding specialization constants for color values or anything more complex.
87
+
88
+
Specialization constants are provided to the CreateDefault argument in content_context.cc and aren't a
89
+
part of variants. This is intentional: specialization constants shouldn't be used to create (potentially unlimited) runtime variants of a shader.
90
+
91
+
Backend specific information:
92
+
* In the Metal backend, the specialization constants are mapped to a MTLFunctionConstantValues. See also: https://developer.apple.com/documentation/metal/using_function_specialization_to_build_pipeline_variants?language=objc
93
+
* In the Vulkan backend, the specialization constants are mapped to VkSpecializationINfo. See also: https://blogs.igalia.com/itoral/2018/03/20/improving-shader-performance-with-vulkans-specialization-constants/
94
+
* In the GLES backend, the SPIRV Cross compiler will generate defines named `#ifdef SPIRV_CROSS_CONSTANT_i`, where i is the index of constant. The Impeller runtime will insert `#define SPIRV_CROSS_CONSTANT_i` in the header of the shader.
0 commit comments