Login

ARM The Architecture For The Digital World  

ARM Community: Making the Mali GPU Device Driver open source - ARM Community

Jump to content

Making the Mali GPU Device Driver open source

Recently we released a major update to the Linux drivers for the Mali-200 and Mali-400 MP GPUs. Like many software projects we time-box our driver development, with two major releases each year. This release (r2p0) contains a bunch of exciting new features including Android support, full SMP support, performance optimizations and some important EGL extensions. We'll talk about some of these in future blog posts, but for today I wanted to tell you about the other big change we made for r2p0: we've started to release parts of the driver stack under an open source license.

People who get excited about software licenses are not necessarily the people you invite to a dinner party for their sparkling conversation and witty repartee. In fact the terms "exciting" and "software license" are used together about as often as the words "glamorous" and "garden shed". Not very often at all. But despite that I'm going to admit that I think this is a pretty exciting change for our Mali drivers!

So what exactly have we decided to open source?

For the r2p0 release we've opened up all the Linux kernel side components of the Mali drivers under the GPLv2. Specifically we've opened up two things:

  • Mali Device Driver – The Device driver is the lowest level of the driver stack and it talks directly to the Mali GPU. It takes graphics rendering tasks from any process in the system and manages them in a prioritized queue. It also deals with interrupts from the hardware when each rendering job is done. Other tasks the Device driver is responsible for include low-level memory management and control of the MMU. It is a powerful and flexible piece of software, and with only minor modification the same component has been ported to a number of different operating systems.
  • Unified Memory Provider (UMP) – The UMP is an auxiliary component which enables memory to be shared across different applications, drivers and hardware components. Imagine your system has a hardware video decoder as well as a Mali GPU. In that system the UMP would allow you to use a video frame decoded by the video hardware as a texture on a piece of geometry rendered by the Mali, without needing to take any intermediate copy. This kind of zero-copy operation is essential when you're dealing with HD resolutions. There are plenty of other things that the UMP can be used for. In fact the UMP is one of our most heavily used pieces of software when we do custom integrations of our drivers. We think this is a really useful bit of code which could be used by lots of other open source projects.

The code is available today from the Mali developer site so download it now and start hacking – we're very keen for people to use this stuff! By releasing the Device Driver and UMP under the GPLv2 license we hope to make it easier to include Mali drivers in all sorts of different Linux products. We're also looking at other ways of distributing the code and talking to lots of partners as well as people like our good friends over at Linaro. Stay tuned.

Going forward, our plan is to update these components each time we make one of our major releases. We may also decide to make other pieces of the driver stack available under an open source license in the future, especially parts of the driver which integrate with important UI infrastructure such as X11, Android or MeeGo.

So having admitted that I get excited about changes in software licenses I guess I shouldn't expect too many dinner party invitations. But if you've read this far then perhaps you too are interested in this change, in which case you may have some thoughts on what we've done. Please let us know if you do. We always love to hear your feedback!

Sam Taylor, Software Engineering Manager - Media Processing Division, ARM, The Media Processing division are the first people to lay hands on each new Mali-GPU. We also get to work at the cutting edge of the Khronos standards, like OpenGL ES, OpenVG and OpenCL.

Before he joined ARM in 2006, Sam used to hang around in high-performance computing research centres, managed to collect a Ph.D along the way, set up a successful graphics start-up, and spent five happy years at Nokia. Fundamentally he likes making stuff – especially if it's fast, small and pumps out polygons at stratospheric rates.

Shortlink to this post: http://bit.ly/9oIk9z
All company and product names appearing in the ARM Blogs are trademarks and/or registered trademarks of ARM Limited per ARM’s official trademark list. All other product or service names mentioned herein are the trademarks of their respective owners.

3 Comments On This Entry

Please log in above to add a comment or register for an account

Page 1 of 1

Suresh Kr Shukla 

08 December 2010 - 09:03 AM
This is interesting progress. Hope to see the whole stack getting opened up, towards faster development and high-quality.However I couldn't find any documentation with this like porting guide/ integration guide etc.
0

JLP 

06 January 2011 - 01:07 AM
Are there any more recent news on progress of opening up more parts of the driver? Any other news about the open source driver?
0

Alison Chaiken 

02 June 2011 - 06:27 PM
The open-sourcing of the Mali driver is a most encouraging development. I understand that binary blobs are still part of the deployment of the driver. Is it possible to get a version of the binaries compiled to use the hardfp extensions? The ABI of the platform I'm working with (http://wiki.meego.co...elopment_Boards) requires hardfp. The automotive industry is very interested in Mali in general and Snowball in particular as a reference platform, but we can't get started without the hardfp driver since our UI requires 3D HW-accelerated graphics. -- Alison Chaiken alchaiken@gmail.com
0
Page 1 of 1
Maximise
Minimise
» 

My Blog Links

» 

ARM Onsite

» 

Search My Blog