© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
OK, I think we just about understand the problem now.
On IRC Alberto pointed out that he was testing with mir_demo_server which will fail to bypass due to its little titlebar. By switching to mir_proving_server that halved the GPU load and everything became smooth.
Alberto also pointed out at least one scenario where Mir 0.25 could only achieve 30FPS but Mir 0.26.1 could briefly sustain 60FPS. So client-side vsync is trying to improve things like it did in bug 1388490.
It appears that by asking the Freedreno chip to render 1920x1080x120Hz (composited, no bypass) we have hit or exceeded the capabilities of the hardware. It's happy at 60Hz with bypass, or with a lighter-weight client like egltriangle instead of eglplasma.
When a client takes too long to render in Mir 0.26, client-side vsync notices and schedules the next frame immediately without delay so that the client might catch up. Normally this works well and does the job of avoiding the large jump down to 30Hz. However a new problem arises if you have a driver that can't timeshare it's CPU very well (like in bug 1211700). If such a driver can't meet the frame deadline, then the new catch-up logic scheduling the next client frame immediately will saturate the GPU, starving the compositor of time to get it to the screen. So you have a very busy client and very few compositor frames.
It seems the answer is that we need to be more attentive to systems that don't have the GPU/CPU power to keep up with their displays, and find an elegant way to throttle them down to a lower framerate without repeatedly trying to catch up and make the problem worse.