-
Notifications
You must be signed in to change notification settings - Fork 28.4k
Consider using a static set of less specialized shaders that can be compiled on startup #77412
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
Comments
Any updates? |
Work is ongoing (@chinmaygarde made a demo of a subset of this for Metal which looks promising), but this is a long-term research project so I wouldn't expect frequent updates. |
For people who wish to follow along with this work, the library was recently merged into the engine tree (very much still as an experiment and nowhere near ready for production, please don't expect this to be available in stable for many many months yet): https://github.com/flutter/engine/tree/main/impeller |
After a preview period since January 2023, Impeller is now on-by-default on iOS in a stable branch. We are now primarily focused on rounding out support for the remaining platforms with Android up next. Impeller uses a static shader set and all shaders are compiled and optimized on our build servers. Depending on the backend, the optimized shader representation is packaged as a blob in the engine and necessary pipeline state objects created at startup asynchronously. There is no runtime shader generation or compilation at all. Closing this issue as completed. |
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 |
Since we currently pay a price (jank) each time a new shader is used, and since some animations end up using a lot of new shaders, one option would be to use less specialized shaders.
If we had a static set of shaders, we could asynchronously compile them on program startup, so that by the time the application runs an animation we can use this static set and not stutter while we prepare a new one.
Medium term we could also determine what specialized shaders we would want to use in each scene, and compile them in the background so that the next time, if all the specialized shaders we would want to use are ready, we could just use them. That way we get the long-term sustained performance benefits of specialized shaders and the short-term smooth start performance benefits of a static shader set.
The text was updated successfully, but these errors were encountered: