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

  • djvita - Monday, June 30, 2014 - link

    do these gpu's offer features similar to amd/nvidia desktop cards? once we get 60fps in manhattan offcreen i'll think it will be enough for graphical performance
  • hansmuff - Monday, June 30, 2014 - link

    Features maybe, performance never. Desktop cards drive large resolutions/multiple screens of the same, provide anti-alias and filtering and high-resolution textures. None of those are needed on a small screen that's just by itself.
  • JemDavies - Monday, June 30, 2014 - link

    The features of modern mobile GPUs are very similar to high-end desktop cards, but obviously the power consumption and performance levels are still different. The environments that our GPUs go into are very different – power is always in short supply, and fans and exotic cooling systems are not appropriate!
  • kron123456789 - Tuesday, July 1, 2014 - link

    Does your GPUs have OpenGL 4.x support? And where are devices with Mali T760MP16?
    Because right now there is no mobile GPU that can beat performance of Tegra K1, and only T760MP16, and maybe PowerVR GX6650, can do that.
  • JemDavies - Tuesday, July 1, 2014 - link

    In most of the markets our Partners are interested in, desktop OpenGL is not a requirement, so we haven’t bothered implementing it.

    It’s not appropriate for me to pre-announce our Partners’ product plans, so I’m sorry I cannot talk about Mali-T760 design wins that haven’t made it into the public domain yet. However, you will see higher core counts designs coming in the future. You have to bear in mind that we only released the IP (RTL) of Mali-T760 at the end of October last year, so we are only just starting to see silicon chips based on it being publicly announced such as the Rockchip RK3288 (MP4), present in the Teclast P90 HD tablet.
  • nfsmw_gr - Monday, June 30, 2014 - link

    Could you release some benchmark results about your coming gpu's in a chart that compares to other high end gpu? For example Adreno 330, PowerVR G6430 and others.
  • ligc - Monday, June 30, 2014 - link

    Many GPU vendors are investing in unified memory and eventually fully cache-coherent interfaces between the CPU and GPU. It is clear that such work is immensely beneficial for GPU compute, but is it useful for graphics workloads, either now or in some graphics pipeline of the future?
  • JemDavies - Monday, June 30, 2014 - link

    Unified memory has been the common system design in mobile devices for years, whilst the desktop machines are only recently trying to move towards this. ARM’s Mali GPUs have been designed from the start for unified memory. The Midgard family of GPUs (from Mali-T604 onwards) supports I/O coherency whereby the GPU can snoop into the CPU’s caches, with support for full coherency coming.

    Graphics workloads might initially thought to be essentially one-way in nature – that the CPU creates some data structures to be consumed by the GPU, to be worked on and then rendered to a frame buffer elsewhere. However, there are cases where cache flushing operations can be avoided by the use of a coherent memory system, with consequent power savings, so yes, it can be a benefit, even with graphics.
  • san_dehesa - Monday, June 30, 2014 - link

    I asked the following questions to Peter last time; but, as he pointed out then, he was a "CPU" guy. Thus, sadly the questions went without answer. Maybe this time is different :) In any case, I highly appreciate the time ARM experts are taking to address the community. Thank you! (and sorry for the long text following; it's a copy-paste from several questions-answers process of last time).

    I would love to know ARM position towards open source GPU drivers now that Intel is putting a big amount of money and effort into developing theirs.

    It seems to me that not taking the open source road for GPU drivers (as ARM is doing) is a big mistake. Furthermore, when the primary OS that host their hardware is running in Android.

    ARM could create much better binaries for free with the work of other talented developers and get better integration with Android in the process. That will be a great selling point for any manufacturer and possible client!
    The Lima project has currently a better performance (5% more) than the close driver distributed by ARM and it is being coded in the developers free time! It would be great to see both teams working together.

    What are the reasons the driver is close-source?
    - Is it that they would reveal a lot of Mali's internal core?
    - Is ARM afraid of IP sues? Having close source will deter patent trolls?
    Intel doesn't seem to have those problems.

    PS: The question is not about whether the drivers should be open or not just because it is morally right or wrong. Obviously it would be nice for the clients and a good selling point, but I was wondering how ARM management see one of their biggest competitor embracing open source when developing GPU drivers.
  • san_dehesa - Monday, June 30, 2014 - link

    I have to wonder how long it will take ARM's legal department to review the driver's code and assess risks. Even if they have part of the blob which is legally binding, they can still open up a big chunk and start chipping in on the advantages of open source developing. There are already developers knowledgeable on their architecture.

    ARM and other chip producers know how much of a pain is to support badly integrated blob of code. When an ARM customer have a problem with the driver, they have to communicate with ARM, wait till they receive an answer, wait till the problem is solved (if it is at all), and then integrate the new blob with their software. So many steps where you can fail! It takes so much time! Mobile products have a really short time-to-market. It would be so easy for everyone if they let their customer help out with the development. Plus, it is free!!

    Samsung (ARM biggest customer) have been testing Intel's products for a while and I am pretty sure that by now they have some developers who know Intel's driver architecture. Don't you think one reason when deciding which platform to choose would be support and time-to-market?

Log in

Don't have an account? Sign up now