When we ran our Ask the Experts with ARM CPU guru Peter Greenhalgh some of you had GPU questions that went unanswered. A few weeks ago we set out to address the issue and ARM came back with Jem Davies to help. Jem is an ARM Fellow and VP of Technology in the Media Processing Division, and he's responsible for setting the GPU and video technology roadmaps for the company. Jem is also responsible for advanced product development as well as technical investigations of potential ARM acquisitions. Mr. Davies holds three patents in the fields of CPU and GPU design and got his bachelor's from the University of Cambridge.

If you've got any questions about ARM's Mali GPUs (anything on the roadmap at this point), the evolution of OpenGL, GPU compute applications, video/display processors, GPU power/performance, heterogeneous compute or more feel free to ask away in the comments. Jem himself will be answering in the comments section once we get a critical mass of questions.

Comments Locked


View All Comments

  • JemDavies - Monday, June 30, 2014 - link

    Thanks for the feedback. ARM has been a huge supporter of Open Source projects over many years, including a key role in the formation of Linaro. We continue to monitor the situation regarding Open Source graphics drivers, and we continually review demand for them from the Partners who license our technology.
  • Hugh R - Monday, June 30, 2014 - link

    ARM would be a lot more friendly to FLOSS is there was at least one performant GPU that was open. That's a strong reason to open the MALI architectures. Not that it's good just for MALI, it's good for ARM.

    I'm surprised to find that x86 works better for me than ARM. For just this reason.
  • libv - Wednesday, July 2, 2014 - link

    The strongest reason is the fact that mali is out on many SoCs, and that integration with other engines is absolutely paramount for good performance and power usage. DMA-Buf was pushed hard by linaro, and it does indeed solve a lot of problems, but cynical old me thinks that Jem Davies is very happy with part of this integration getting solved by dma-buf, and that the remaining integration will be swept under the rug.
  • melonfresh85 - Tuesday, July 1, 2014 - link

    So basically, your answer to the underlying elephant question in the room that this feedback is getting at is "unless Samsung make a request for open source drivers for their Galaxy phones that incorporate Mali GPU's, developers on XDA will continue to be banging their heads against the wall trying to develop up to date Android builds for phones Samsung no longer cares about"

  • JemDavies - Wednesday, July 2, 2014 - link

    I really do understand your frustration and I’m sorry that this makes life harder for you and similar developers. We are genuinely not against Open Source, as I hope I’ve tried to explain. I myself spent a long time working on the Linux kernel in the past and I wish I could give you a simple answer. Unfortunately, it is a genuinely complex problem, with a lot of trade-offs and judgements to be made as well as economic and legal issues. Ultimately I cannot easily reduce this to an answer here, and probably not to one that will satisfy you. Rest assured that you are not being ignored. However, as a relatively small company with a business model that is Partner driven, the resources that we have, need to be applied to projects in ways that meet Partner requirements.
  • libv - Wednesday, July 2, 2014 - link

    Hi Jem, I just grepped a kernel tree (which does not include the commit history from the bitkeeper days), and the commit log, and i couldn't find you. I did find David, Liam, Tim, Steve, Jonathan, and even Craig Davis. Can you point out what linux kernel subsystems you worked on and in what timeframe?

    About resources, I believe that we two communicated about this before. It included a pretty solid project outline and reasonably delineated resources, especially given the massive commercial success that ARM is enjoying these last "few" years.
  • happosai - Tuesday, July 1, 2014 - link

    Jem, why not have redistributable binary-only drivers like nvidias linux-for-tegra kit? it would be a major step forward. Currently one cannot seriously consider mali for gpu compute projects, when the availability of non-android mali drivers depend on the goodwill of arm, soc vendor and product vendor.
  • JemDavies - Wednesday, July 2, 2014 - link

    happosai - thanks for the suggestion, which is a good idea. In fact, it’s such a good idea that we do it!  The Open Source organisation Linaro, that we are a member of, host binary drivers, e.g. for the popular Arndale development board.
  • JemDavies - Wednesday, July 2, 2014 - link

    happosai some additional info.

    Please see following link: http://www.linaro.org/downloads/

    If you go to the Linaro Engineering Builds (LEBs), the Arndale, Nexus 10 and now as of today the Juno BSPs are available with the Mali driver user side binaries. (breaking news, as the public announcement for Juno has only just gone out).

    I should also mention that the Mali kernel driver is now part of the Linaro Stable Kernel (LSK) regardless of the user side binaries being included in the LEBs or not.
  • ssvb - Wednesday, July 2, 2014 - link

    Thanks. But these downloads seem to have a rather discouraging disclaimer - "Note: Ubuntu flavoured images released as Linaro engineering builds are not for production use, modification or redistribution, but are to be used for evaluation purposes only". It does not look like they are really redistributable yet. And this prevents the end users from having usable graphics drivers in the popular Linux distributions out of the box.

    The Mali kernel module is not a problem, because it is a GPL licensed free software since a long time ago. The Linaro Stable Kernel (LSK) is nice, but not really necessary.

Log in

Don't have an account? Sign up now