• Locked Locked
  • Replies 3 replies
  • Subscribers 136 subscribers
  • Views 5584 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

warning when starting MMU on TCC8900

Juuso Takalainen
Parents
  • Note: This was originally posted on 10th June 2010 at http://forums.arm.com

    Hi Juuso,

    The Mali hardware has a range of memory it is permitted to write to directly. Typically, this should only cover the device's framebuffer memory region. The range is configured when the Mali driver is built. When the ranges match, the Mali hardware writes output directly to the framebuffer's back buffer, and on eglSwapBuffers() it waits for VSYNC and swaps the front and back buffers. We call this "direct rendering" and this is the expected and best use case from a performance point of view.

    If a Mali binary driver and a Linux kernel become mismatched (e.g. the platform provider moves the framebuffer in the kernel's physical memory map) then the Mali is no longer permitted to write directly to the framebuffer region. In this case, the Mali will drop back to what we call "blitting" where essentially the Mali hardware must render to some 'private' memory it has allocated, and then the CPU must copy (which the kernel memory manager will allow) the rendered buffer to the framebuffer memory region. In this scenario the output will only be single buffered, and eglSwapBuffers() will not wait for VSYNC, so the output may appear faster but less smooth, and will likely suffer from 'tearing' visual artefacts.

    The correct solution to the problem is to ensure the platform provider configures the Mali driver binaries with a suitable memory range which will cover the present Linux kernel's framebuffer memory layout, and update the driver binaries if the kernel memory map changes. What is happening in your case is that the platform provider has somehow got the supplied Mali driver binaries out of sync with their supplied Linux kernel.

    I'm afraid the guide mentioned in the driver message is for Mali silicon licensees - only they are entitled to the ARM Mali Software Integration Guide, which they use to adapt our Mali driver source code to their platform.

    HTH, Pete
Reply
  • Note: This was originally posted on 10th June 2010 at http://forums.arm.com

    Hi Juuso,

    The Mali hardware has a range of memory it is permitted to write to directly. Typically, this should only cover the device's framebuffer memory region. The range is configured when the Mali driver is built. When the ranges match, the Mali hardware writes output directly to the framebuffer's back buffer, and on eglSwapBuffers() it waits for VSYNC and swaps the front and back buffers. We call this "direct rendering" and this is the expected and best use case from a performance point of view.

    If a Mali binary driver and a Linux kernel become mismatched (e.g. the platform provider moves the framebuffer in the kernel's physical memory map) then the Mali is no longer permitted to write directly to the framebuffer region. In this case, the Mali will drop back to what we call "blitting" where essentially the Mali hardware must render to some 'private' memory it has allocated, and then the CPU must copy (which the kernel memory manager will allow) the rendered buffer to the framebuffer memory region. In this scenario the output will only be single buffered, and eglSwapBuffers() will not wait for VSYNC, so the output may appear faster but less smooth, and will likely suffer from 'tearing' visual artefacts.

    The correct solution to the problem is to ensure the platform provider configures the Mali driver binaries with a suitable memory range which will cover the present Linux kernel's framebuffer memory layout, and update the driver binaries if the kernel memory map changes. What is happening in your case is that the platform provider has somehow got the supplied Mali driver binaries out of sync with their supplied Linux kernel.

    I'm afraid the guide mentioned in the driver message is for Mali silicon licensees - only they are entitled to the ARM Mali Software Integration Guide, which they use to adapt our Mali driver source code to their platform.

    HTH, Pete
Children
No data