-
Notifications
You must be signed in to change notification settings - Fork 953
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
GLES: Cache and reuse programs between similar pipelines #3380
Conversation
…ng the same program untold many times
Codecov Report
@@ Coverage Diff @@
## master #3380 +/- ##
==========================================
+ Coverage 64.64% 64.68% +0.04%
==========================================
Files 86 86
Lines 42722 42780 +58
==========================================
+ Hits 27616 27673 +57
- Misses 15106 15107 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea, good execution, have some questions/comments but looking forward to getting this in.
You re-requested review but didn't push anything 😄 |
That's... huh. Where the hell am I pushing things?! |
I had a bunch of commits since I made the PR and apparently I've been pushing them to the wrong place. I'm juggling too many things 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
G2G after nit
Thanks for all your help on the GL backend! |
Hello, may I ask if it’s possible to cache and reuse similar pipelines based on a similar approach, rather than just caching the program? This would help save time in assembling WebGL pipelines. |
It sure could be done, but the idea here is that only the program creation is the actual slow part. Everything else is mostly just ephemeral state that needs to be set during rendering, so I don't think there is any speedup to be gained. |
Checklist
cargo clippy
.RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown
if applicable.Connections
None
Description
It's a common practice to create many, many pipelines due to a lot of state being "per pipeline" and not adjustable on the fly, such as blend modes. This turns them into an often giant explosion of permutations for shaders vs blend vs depth operations (and other things). As the GL pipeline unfortunately needs to block on the creation of each program, and we create one program per pipeline, this can lead to stalls over 10 seconds long as we create the pipelines needed for our application.
This change decouples a Pipeline from a GL program, and allows sharing of the same program across many pipelines. As long as the inputs are the same, the program created will always be the same and thus can be shared safely.
For ruffle with webgl, this reduces a startup time from about 10 seconds to almost instantaneous due to the amount of programs we create, for a very few combinations of shaders.
Testing
All the existing tests pass and I've monitored that programs do indeed get destroyed when every pipeline that uses them is deleted.
I've manually tested Ruffle with this change to confirm the speedup, and it's fast and stable.
I haven't created any new tests, I'm not sure how to test this automatically.