This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DP500 + Software Rendering Question

Dear Experts,

We are trying to solve an issue where we see at Android startup, each frame takes a long time to display i.e. frame rate is slow. With a debug enabled mali driver, we see that rendering is taking a long time compared to display - we can make this conclusion by analyzing the timestamps against malidp_adf_validate and malidp_adf_post traces.

The questions I have are;

1. In a typical v8 linaro kernel, does the software rendering engine refer to any particular clock input to configure its rate of schedule?

2. If not, presumably, there should be another way to configure the rate of rendering within the kernel as it is only logical that there should be a way to set that?

3. Or could it be that we be missing a clock entry in the device tree so the rendering engine is running at a default rate?

I realize I am giving limited information here but would really appreciate some input.

Kind Regards,

Top replies

Peter Harris over 9 years ago in reply to JayC +1 verified

Hi JC, I'm surprised Android really gets very far without a hardware GPU; there is some limited emulation of OpenGL ES 1.1 functionality in software for the UI, but in the newer versions more of the UI...

0 Peter Harris over 9 years ago
Hi JC,
I'm not entirely sure what you are meaning by "software rendering engine" here, but some general advice below.
In normal operation Android had a three stage rendering operation.
Application uses the Mali GPU to render to application framebuffer.
SurfaceFlinger uses HWComposer to turn a set of application framebuffers something the Mali DP can handle (this will often be a no-op - Mali DP can do a lot of composition tasks natively - but not always).
SurfaceFlinger send the final set of surfaces to Mali DP for scan-out to screen.
If things are running slowly things to check include:
Check all of your clock rates.
Check your N-buffering to ensure things stay pipelined (Android normally uses triple buffering for applications, but it's configurable). With double buffering then you'll starve for buffers if you are using vsync, and lock to approx an integer division of your screen refresh rate.
Try disabling vsync - if that helps then it points to the above being the problem.
Check that your HWComposer integration is correctly sending things to the Mali DP. The default HWC for Android is to use the GPU to flatten everything into a single surface before scanout, which will use the Mali GPU. It's much more efficient to get HWComposer to use the native multi-layer support in the Mali DP whenever possible, as it avoids this intermediate flattening operation completely (faster, lower power, lower bandwidth).
It sounds like you are a licensee, so I'd suggest raising a support case - it's easier to discuss technical details via that route.
HTH,
Pete
Cancel
Up 0 Down

Cancel
0 JayC over 9 years ago in reply to Peter Harris

Hi Pete,
Many thanks for your feedback, I have to go through it in detail.
With regard to my reference to "software rendering engine" basically, this platform has no dedicated hardware GPU so rendering is done in software and that is what I was referring to.
Would that affect anything you described above?
Kind Regards,
JC
Cancel
Up 0 Down

Cancel
+1 Peter Harris over 9 years ago in reply to JayC

Hi JC,
I'm surprised Android really gets very far without a hardware GPU; there is some limited emulation of OpenGL ES 1.1 functionality in software for the UI, but in the newer versions more of the UI is using OpenGL ES 2.0 which requires GPU hardware to be present. And yes, emulation of OpenGL ES 1.1 in software is really really slow so if you are hitting this path then it wouldn't surprise me that your framerate is very low.
You can use something like DS-5 Streamline to profile your system and see where it is spending CPU time.
HTH,
Pete
Cancel
Up +1 Down

Cancel