[juuso]

Hi,

I keep getting these when I launch a program. Could you give a link where I can download the mentioned guide, and perhaps also point out the relevant page?

Example programs work quite ok, but some "real-life" graphics applications just go horribly slowly. This might have something to do with it?

-- Juuso


----------------------------------------------------------8<----8<----8<-----------


Mali<2>: MMU session begin
Mali<2>: Page directory for session 0xc4a973e0 placed at physical address 0x40F44000
Mali<2>: MMU session begin: success
Mali<2>: Core: session_begin: for Mali200
Mali<2>: Core: session_begin: for MaliGP2
*******************************************************************************
MALI PHYSICAL RANGE VALIDATION ERROR!

We failed to validate a Mali-Physical range that the user-side wished to map in

It is likely that the user-side wished to do Direct Rendering, but a suitable
address range validation mechanism has not been correctly setup

The range supplied was: phys_base=0x45200000, size=0x000BC000

Please refer to the ARM Mali Software Integration Guide for more information.

*******************************************************************************

[Pete]

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

[Habbakuk]

Quote

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.

So it is a problem on the third-party provider's side, and not Mali's, correct?

This post has been edited by Pete: 09 December 2011 - 03:44 PM

[Pete]

Hi,

yes - usually the board supplier just needs to rebuild the Mali binary drivers, correctly specifying the memory region the board can use for the framebuffer device. This can move if the kernel is reconfigured as it may change how many peripheral drivers are included - and each driver may be reserving some of the system memory map for its own uses.

Mali will only direct-render to the framebuffer if the driver has been told it is permitted to write to that memory region.

HTH, Pete