Mali drivers slower when resetting state after uprev |
||||
Issue descriptionWe noticed that Mali drivers regressed in terms of CPU performance on Dru when setting GL states. While investigating crbug.com/843525 we noticed that a regression happened in this range: 10502.0.0 ~ 67.0.3375.0 ---> Bad 10488.0.0 ~ 67.0.3369.0 ---> Good Mali uprev landed between those two versions. Running a trace before and after with similar workloads shows that we now spend more CPU time than we used to in GLES2DecoderImpl::RestoreState. Attached two traces, trace_hhh was taken before the regression and trace_ggg after the uprev. Between seconds 2 and 2.5 the workloads are similar. The GPU process main thread (CrGpuMain) is completely busy in trace_ggg while it has some free time in trace_hhh. The main difference seems to be GLES2DecoderImpl::RestoreState that after the regression takes up to 6ms, while before it used to take less than 1ms. It also seems that wall time increased significantly, while CPU time didn't.
,
Jun 20 2018
,
Jun 22 2018
marcheu@, could you help in triaging this?
,
Jun 22 2018
Anders is already CCd, there is nothing to do
,
Jun 26 2018
Arm Ref MIDCET-2030
,
Jul 20
,
Jul 24
Still under investigation by ARM. Did we do anything on the Google side to try to work around this?
,
Jul 24
@#7: We really noticed this issue only for low latency clients where they'd be drawing on each input event (multiple per frames). Google side we added a completion query on the low latency client to throttle GL commands. It'd be still nice to get the old performance when restoring state, if possible.
,
Jul 25
The client-side fix still does not make Kevin's latency as low as it was before this regression. |
||||
►
Sign in to add a comment |
||||
Comment 1 by dcasta...@chromium.org
, Jun 20 2018