-
Notifications
You must be signed in to change notification settings - Fork 26.7k
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] Potentially poor performance with Vulkan on Motorola Edge 30. #148493
Comments
Seems like this could be related to my issue #148496 too with IOS jank in impeller on ListView scrolling. This doesn't happen when running with Skia. |
Motorola Edge 30 Regular
I wasn't able to compile the project for Android, I got this error:
|
Thanks for confirming. I'm trying to get my hands on this device now and will try to reproduce the performance observations. Thanks for the comparison of the blurs. You also mentioned gradients. Do you have screenshots of those too. Or is it all gradients? If so, we can setup a reduced test case for those on our own. |
@ercantomac can you create a minimal test case that shows how you're using blurs? |
Also I don't think flutter/engine#51761 is in 3.22, so since blurs use mipmaps for the downsample I'd expect lower fidelity. Will confirm next week, otherwise you could try on master channel |
Assigning to myself to track getting our hands on this specific device. |
After comparing the screenshots closely, I realized that they are nearly identical after all, so I guess I was wrong about the gradients. |
I wrap my widgets with this widget:
And here is the noise.png file: |
Thanks for clarifying the gradients and the reduced test case on the blurs (will take a look). I've placed an Edge 30 on order and should have it in hand ~ May 24-29. |
On PerformanceI have the Edge 30 on hand. I locked the screen refresh rate to 144Hz (from the default "Auto") and cycled thorough the macrobenchmarks and didn't notice any performance degradation. On simple scrolls, frame times are 2-3 ms which is well within the ~7ms frame budget. I was able to observe dropped frames on a couple of benchmarks like "Animated complex opacity perf." The stalls are in next drawable acquisition which means its the GPU workload that is too high for a sustained 144Hz frame rate. Unfortunately, my Edge 30 can't receive updates past Android 12 so the GPU frame capture tools aren't suitable. But, the same scene renders in ~10ms on the GPU on the Pixel 7 and is barely within the 90Hz budget on that device. But that scene isn't faster with the old renderer either. There isn't a reduced test case for the "simple scrolls" performance issue in the original post but we have been able to reproduce @voxelbee s report and are working on improving that case. So my takeaway for the team is to make progress on that actionable issue (and they are). If you have more information on what you are rendering in the "simple scrolls", that'd be super helpful. On Blur FidelityI was able to observe a difference in the blur fidelity like you reported. I've filed #149431 to track closing that gap. On Gradient FidelityLike your update, I wasn't able to reproduce any differences. ConclusionWe have a couple of actionable issues to work on that I've cross-referenced. I'll keep an eye out for reduced test cases of the buggy simple scrolls. Closing this issue as I am concluding my investigation. Thanks for previewing the renderer. You are helping more than you think you are. |
Working title as I'm still investigating. This is based on this report on Reddit.
The user reports poor performance ("less fluid on simple scrolls") and loss of fidelity ("quality of backdrop blurs and gradients").
The device is a Motorola Edge 30. The GPU Info report says it is an Adreno 645L and it has a 144Hz screen. GPU Info had listings for a Motorola Edge 30 Pro, Fusion, and Ultra and I need to verify which one the user has.
I've tried to reproduce this observation on the high refresh rate device I have on me right now (Pixel 7 Pro) and was unsuccessful (also with the
macrobenchmarks
app). Though, I also think we only have devices that go up to 120Hz in the lab. Though I don't see how, perhaps the 144Hz is relevant to swapchain setup? Just a guess.The loss of fidelity is also difficult to explain since the implementations are identical between the backends for stuff like blurs (theres only so many ways to blur stuff and we did do the dithering fixes as well). My guess here is again something to do with the swapchain setup as we don't do that in the OpenGL backend for Skia and perhaps we messed up the surface format.
I'll try to get more information from the original poster but the action item for the team is to get our hands on a Motorola Edge 30 with a 144Hz panel.
Questions for the original poster:
flutter run
in that directory)?s
afterflutter run
)? Both the before and after?I'll followup on getting our hands on the device of this kind as it seems like a good configuration to have on hand. Its a high refresh-rate device at a non-standard rate with a great screen and an upper-mid tier GPU.
The text was updated successfully, but these errors were encountered: