• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 136 subscribers
  • Views 3152 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

JayC

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,

JC

Parents
  • 0

    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

Reply
  • 0

    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

Children