Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Pelion IoT Platform
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
Tools and Software
Graphics and Gaming
Jump...
Cancel
Graphics and Gaming
Graphics and Gaming forum
warning when starting MMU on TCC8900
Blog
Forum
Videos & Files
Help
Jump...
Cancel
New
Replies
3 replies
Subscribers
133 subscribers
Views
3051 views
Users
0 members are here
Memory Management Unit
Mali Drivers
Related
warning when starting MMU on TCC8900
Offline
Juuso Takalainen
over 7 years ago
Parents
Offline
Pete
over 7 years ago
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
Cancel
Up
0
Down
Reply
Cancel
Reply
Offline
Pete
over 7 years ago
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
Cancel
Up
0
Down
Reply
Cancel
Children
No data
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Not Answered
Mali-G71 GPU glReadPixels slow compared to linux desktop equivilant for Default Framebuffer
+1
Android OpenGL ES
Mali-G71
Graphics APIs
5936
views
0
replies
Started
3 months ago
by
Matthew Good
Answered
Camera feed not showing on Mali-based chips
0
vulkan
Mali DDK for GPU (Midgard Architecture)
Mali GPU (Bifrost Architecture)
OpenGL ES
vulkan api
Mali DDK for GPU (Utgard Architecture)
6835
views
6
replies
Latest
3 months ago
by
Peter Harris
Not Answered
Is it possible read separated Alpha/RGB pixels for rendering?
0
9471
views
0
replies
Started
4 months ago
by
YoungJun
Answered
Query on FPK Occluder
+1
Mali GPU (Valhall Architecture)
arm streamline
9430
views
1
reply
Latest
4 months ago
by
Peter Harris
Not Answered
GLES enabling in BGFX for MAME
0
9575
views
1
reply
Latest
4 months ago
by
Yash Anand
<
>
View all questions in Graphics and Gaming forum