-
Notifications
You must be signed in to change notification settings - Fork 28.9k
Sped up shader warmup by only drawing on a 100x100 surface #36482
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
Conversation
the draw calls on top of each other.
It looks like this pull request may not have tests. Please make sure to add tests before merging. While there are exceptions to this rule, if this patch modifies code it is probably not an exception. Reviewers: Read the Tree Hygine page and make sure this patch meets those guidelines before LGTMing. /cc @dnfield |
Why not a 10x10 or a 1x1 surface instead? |
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! Can you please add some tests to:
- Verify the number of shaders being warmed up is as expected.
- Measure the total time of shader warm-up so we can track it in our dashboard (instead of doing an observatory tracing manually every time)
@@ -157,22 +155,18 @@ class DefaultShaderWarmUp extends ShaderWarmUp { | |||
canvas.save(); | |||
for (ui.Paint paint in paints) { | |||
canvas.drawPath(paths[i], paint); | |||
canvas.translate(80.0, 0.0); |
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.
One reason that we added these 80.0 offsets is to visualize the warm up draws in examples/layers/raw/shader_warm_up.dart
. Can you please add a flag here to preserve the offset in that debug app? (Maybe it's nice to do some refactor to force each draw within an 100x100 area, and automatically stack them together for actual warm-up and spread them for debugging.)
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.
Done
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.
Can you please also set the _drawCallSpacing
to 80.0 in examples/layers/raw/shader_warm_up.dart
?
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.
@gaaclarke : any comment on this?
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.
Done.
The draw calls have to be onscreen. We might be able to drop below 100x100 by tweaking the draw calls, but at 100x100 our read pixels is 4ms. I don't know if we'll be able to drop much below that. (Ideally we don't even read pixels but I've given up on that for now). |
I realized that "adding a test to verify the number of shaders being warmed up is as expected" could be a little complicated, so I'm Ok to just have it manually checked for this PR, and maybe add it as a test in another dedicated PR. On the other hand, add a test to measure the total time of shader warm-up so we can track it in our dashboard (instead of doing an observatory tracing manually every time) shouldn't be very difficult. For example, you can create
You can then write a device lab driver test to report the measurement: https://github.com/flutter/flutter/tree/master/dev/devicelab Please let me know if you have any questions about the device lab test. Ideally, maybe we can land the driver test before the merge of this PR so we can get an official number of how much time is saved on our test devices 😄 |
Hey Yuqian, I looked into this and it doesn't seem trivial. Whatever tests covered this code previously should cover this PR. I'm not sure if continual tracking of shader warmup is something we want to do, considering the effort to do so. This is demonstrably faster with profiling. I agree that the benchmark would be nice to have, but I'm failing to see how it is a good return on investment. Let's chat tomorrow. |
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.
LGTM modulo the analyze warnings.
The 2 outstanding tests have passed, they just aren't reporting so here for some reason. |
…6482) Sped up shader warmup by only drawing on a 100x100 surface and doing the draw calls on top of each other.
I'm investigating the historic slowdowns in the It appears that this commit is responsible for that change. Here are 3 runs of the benchmark on a Moto G4 first running on commit 0d0af31 (which is just before this commit) and then on this commit 9b150f1
|
…lutter#36482)" This reverts commit 9b150f1.
See #40406 |
Description
...and doing the draw calls on top of each other.
big.json.gz
little.json.gz
In big.json you'll see how the code was previous, and in little.json you'll see how it is after this PR. This saves about 14ms in readpixels.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]
). This will ensure a smooth and quick review process.///
).flutter analyze --flutter-repo
) does not report any problems on my PR.Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?