-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Impeller] support static shader variants using specialization constants #119357
[Impeller] support static shader variants using specialization constants #119357
Comments
Rather than performance, we may consider this as a means to drive down bundle size on Android. Right now we have a decent amount of shader duplication between the advanced blends, and additionally a bit with blurs. We could probably reduce our bundle size by at least a few Kbs by instead expressing the shaders as a big switch over specialization constants. We'd need to build support in the tool for "unrolling" these for GLES though. |
The current mystery here is how to use specialization constants with GLES. The SPIRV output contains Additionally, impellerc cannot handle multiple output files. |
Reland of #47432 Also includes: * #47617 * #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. Fixes flutter/flutter#136210 Fixes flutter/flutter#119357
…47762) Reverts #47678 Initiated by: jonahwilliams This change reverts the following previous change: Original Description: Reland of #47432 Also includes: * #47617 * #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. Fixes flutter/flutter#136210 Fixes flutter/flutter#119357
Reland of #47432 Also includes: #47617 #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. Fixes flutter/flutter#136210 Fixes flutter/flutter#119357 Investigating: flutter/flutter#138028
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Originally in go/impeller-shader-variants, related to #116103
Problems
Some shader source code is highly repetitive due to blend mode implementations (i.e drawAtlas, drawVertices, or blends). Branching on blend mode is likely to be prohibitively expensive.
Arm Mali GPUs suffer from substantial performance overhead compared to iOS GPUs when branching on uniforms. Dramatic performance improvements can be achieved on Android by creating variants for common shaders (See: Make ColorFilterLayer accept an offset engine#38055 , [Impeller] improve rrect blur performance on Android engine#37925 , [Impeller] Improve border_mask_blur performance on Android engine#37923 , [Impeller] improve morphology performance engine#37918 )
Maintaining mostly duplicate shader sources is cumbersome and likely to be error prone in the future.
Registering and looking up different shaders is highly repetitive
Every shader we add slightly increases startup time. At this point its not a problem, but needs to be managed. Tracked in [Impeller] Benchmark PSO library construction in the constructor of the content context. #117180
Specialization constants
spriv-cross seems to mostly do reasonable things with specialization constants declared in a shader.
For example, with the morphology filter:
For GLES, the following code is generated:
For Metal, the following code is generated:
We'll probably need to do some plumbing to set it but it might do what we need.
We'll still need to declare all of the possible values ahead of time. This will allow us to generate specialized versions for GLES and have correct bindings for metal, which seems to need all possible values during pipeline creation.
From Metal documentation:
AIs
The text was updated successfully, but these errors were encountered: