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

  • ciplogic - Tuesday, July 1, 2014 - link

    Some underlated questions:

    1. Does it make sense to have DDR5 or soemwhat faster memory bandwidth on the high end tablets/phones? Here I talk as a real novice on this field.

    2. Without asking design wins, do you think it would be possible to make a entry-level laptop using just ARM technology? (Please give even a PR like of answer, but as for me I've seen just locked in laptops for now: Chromebook/Windows RT-Tegra tablets/laptops)

    2. Is on Android's VMs on ARM GPU emulation accurate? How would you recommend to test/fix GPU driver bugs if they are reported by someone using Mali GPUs?
  • JemDavies - Wednesday, July 2, 2014 - link

    Memory technology is moving on quite quickly. Most of our partners are using LPDDRx, as it is lower power, but some do use DDR as well, particularly in tablets. Graphics uses large amounts of memory bandwidth and while we design our GPUs to be as efficient as possible in terms of their bandwidth usage, if the content displays complex images at high resolution and high frame rate, then the bandwidth used can be very significant indeed. As a consequence, GPU performance can be throttled if it doesn’t get the bandwidth it needs.

    I’m not sure what you mean by locked-in. ARM-based laptops running Linux have been around for many years, and there are ARM-based Chromebooks available today. I believe the one based on ARM CPU and ARM Mali GPU is still one of the most successful to-date…

    Any bugs in our drivers are best reported through our support channel if they have a support contract with us, or on the Mali developer website (http://community.arm.com/groups/arm-mali-graphics) if not.
  • darkich - Tuesday, July 1, 2014 - link

    Mr. Jem, with your position in the mobile GPU field, you should feel a special privilege since mobile GPU is the fastest advancing technology in history.
    I have calculated that if the current rate of performance growth of mobile and desktop graphics would remain unchanged, the mobile GPU would actually catch up with desktop by 2025, and make it ridiculously obsolete in 2026.

    Now, if we agree that this theory can never actually happen, the obvious question arises- for how long do you think this phenomenal advancement can continue?
    How much room you think is left for development?
    Do you see mobile GPU's soon facing limitations similar to those we see in the desktop space?
  • darkich - Tuesday, July 1, 2014 - link

    P. S. apologies for using the technically wrong term. By "mobile GPU" I was referring to smartphone /tablet ULP graphics of course
  • JemDavies - Wednesday, July 2, 2014 - link

    Thanks for the comments. Yes, I think I am really lucky: this is a truly great job. I get to work on some really cool technology and I have the privilege of working with some of the best people in the industry.

    Actually, I don’t think it’s that useful to compare mobile GPUs with desktop GPUs. We’re all engineers: we get a problem, we explore round the problem, we see what the design constraints are, we understand the technology available to help us solve that problem, we invent some new stuff, and we attempt to solve the problem. That’s what we do. The desktop guys were given a different problem to solve: the best possible graphics within 300-400 Watts of power and lots of silicon. We’ve picked a different problem: a different power budget, and rather than making consumer products, we’re making component technologies to enable our Partners to make different, great consumer products. Obviously, I think our problem is the most interesting problem to solve (that’s why I am here), but there are great and interesting challenges ahead for the guys in the desktop area as well, and there is no way that they are standing still: they continue to innovate every bit as hard as we do.

    Roughly, roughly, the “customers” (very approximate usage of the term) want a doubling of “performance” (again, approximate) every year. I know, incredible but true. Will that end? I think not for some time. We do not have visual realism yet in graphics. If you watch a CGI movie, you are fooled. It looks undeniably real, but if you ever freeze frame and look closely, you can usually see that it isn’t real within a few seconds of examining the screen. We just don’t have the capability to produce genuine realism yet (and those frames of images probably took 8 hours or so each to render on a state-of-the render server farm, with immense compute power). So, we have a hard technical problem to solve, and continuing consumer demand to have that problem solved. Consumers (rightly) don’t give a stuff that we don’t have the same compute horsepower available in mobile devices or televisions: “Not my problem” they say. Consumers have seen CGI movies; they have played high-end games on consoles; they have seen great-looking naturally compelling and fluid user interfaces. Most don’t know that they want higher resolutions so they can’t actually make out the individual pixels, or higher frame rates so that the visual effects seem smooth and buttery”. Most don’t know anything about high dynamic range, or color gamut, but if you show them one device that has some of these new technologies and one that does not, that will be a quick and easy choice for them. So, we have a clear and pressing roadmap of demand from customers that will continue for some time.

    Advancements come in many different areas. For some years, we have had a bit of a free ride from Moore’s law, whereby (wildly paraphrasing, and you really should read up on what he actually said) every year we can have more frequency (performance) and more transistors for the same amount of money spent by the silicon Partner. There has been much speculation about the end of Moore’s law, and it would take a whole blog entry for me to write about that, so let’s just agree that the effect is *changing* and that we won’t get as much of a free ride in future. APIs are changing as well. There have been some questions here about the impact of Mantle, and Metal, and the way that this may change the world of graphics and the way that the content is changing. Display standards are changing as well. We have new physical interfaces, and we have Display Stream Compression, but we still largely still pretend that we’re talking to a CRT and shift data out serially in sequence: that will change as well.

    One of the technical trends that interests me is the cost of computing a bit versus the cost of transmitting a bit. What do I mean by that? Well, if we look at video standards like HEVC and VP9, they are becoming computationally more complex to achieve better compression ratios (or better quality for the same bit-rate - it’s the same thing). We have traded extra compute requirement (at each end of the “wire”) for lower transmission and storage costs. It’s the right thing to do because FLOPS are trending towards free, whereas storage and transmission are not reducing in anything like the same way. One of our memory experts gave me the “10,000 FLOPS for the energy cost of loading a cache line” catch-phrase the other day. Of course there are more caveats in that than you can imagine: it depends entirely on the silicon process, the size of the cache line (if you ever want a really good argument, get a bunch of processor and memory system engineers in a room and ask them what the ideal cache line size is), the type of RAM and a whole host of other things, but as my boss used to say “It’s roughly right, even if exactly wrong”. So, we have some really interesting technology trends that are affecting the way in which we design the graphics, video and display processors. I think there is plenty of room left for development.
  • darkich - Wednesday, July 2, 2014 - link

    Thank you so much.
    An amazing response and much more than I hoped for.
    Kudos to you sir, and to ARM for doing this.
  • milli - Wednesday, July 2, 2014 - link

    Have many of the original Falanx employees stayed with ARM Norway? Does the current (core) staff in any way resemble the old one?
    How does the communication happen with ARM in UK?
    Who decides on the future path of Mali? ARM Norway?
    And one last question, why did the choice fall on Falanx in 2006? Back then there where many options. I would assume that even UK based Imagination Tech wasn't out of reach for a takeover.
  • JemDavies - Wednesday, July 2, 2014 - link

    A lot of the original Falanx employees stayed with us. Even the CEO (who you might expect to go off and do another startup stayed for around four years (before going off to do another startup - and we remain in touch, he’s still a friend of mine). Two of the four founders remain with us today, including the chief GPU architect (who is now also a Fellow in ARM). However, the original company was 25 staff. We now have over a hundred and twenty people in Trondheim (Norway), and we have had to move offices twice since the takeover as we outgrew the premises! So, it’s changed a lot in some ways, but stayed very much the same in others.

    Communications take place at all levels. We use email, we use Skype, we use audio conference calls, we use video conferencing, and we also put people on planes (sometimes there is no substitute for being in the same room and I haven’t yet seen the electronic whiteboard that can work as well as a napkin when in the same restaurant!). Of course it’s not just Trondheim<->Cambridge. We now have development being done in Cambridge, Trondheim, Lund (Sweden), San Jose (California, US), Shanghai (China) and Hsinchu (Taiwan).

    The future path of Mali gets decided at different levels. ARM encourages decisions to be made at as low level as possible. Mostly that’s engineers making design choices: they are the best-qualified and best-placed to do so, and they do a great job of it. At a higher level, there’s a group of architects, and I suppose I get a lot of say on the future technology strategy, but I have great experts around me to advise. There are also our colleagues on the commercial side, who give us very useful advice on that side of things. Last, but by no means least there are our Partners. We have long-term and close relationships with a lot of our Partners, and we make sure our engineers get good contact with them as well as the commercial people. They trust us and tell us what they need, where they think improvements can be made, they advise us on trends coming our way that we might have missed, you name it. They are (rightly) a very demanding group, but the impact they have on our thinking and our roadmap is very significant.

    I was part of the team that performed the initial selection process, which actually started in 2005, when it was clear how important graphics and other elements of visual computing were going to become. We did indeed, look at a lot of other companies back then, and we were confident then that we got the best choice, and I remain equally convinced to this day. Having been part of the teams that have done a number of the Media Processing Group in ARM’s acquisitions, I know that the selection process can be complex and wide-ranging. Of course there is the technical evaluation, but also, you are selecting critical people. You have to ask “Can I work with these people?”, “Will they enjoy working at ARM? (Unhappy people don’t work well)”, “Can we and they take what they have and turn it into what we need?”. You are not just buying technology into ARM, you are buying people (hopefully great people), who will become part of ARM’s future. If we invest in them and develop them, what other things can they do for us? Will they make our next generation of ideas that will be technically and commercially successful? Brilliant companies are all the time looking for ways to make the company better than they are already: “Do they have someone who can take my place?”, for instance.
  • BMNify - Wednesday, July 2, 2014 - link

    hi jem, your latest Juno development platform is rather a let down, i suppose its because of the focus on the industrial customers rather than ever focusing on the real end users that pay for the products they want to buy and that's shame...


    the fact this does not have even USB3 never mind USB3.1 functionality given the IP is available now, and the fact its only got a modest Mali T-624 core seems wrong for a new PCB for development work, i also question the wiseness of not using your best generic CoreLink CCN-508 interconnect to date here, how can we assess you best IP if we cant buy it in a functional cost effective Development Board (ODROID/NVIDIA Denver Tegra K1 PCB etc style).

    what are your expectations for this "Juno" Mali T-624 with slower CCN NoC with two Cortex-A57s, four Cortex-A53s, and no apparent options to use lowest power and fastest WideIO2 or HMC , or a way to even bring the CCN to the IO ports for best 3rd party expanability ?, people as in the actual end consumers want fastest Cortex IO everywhere not some limited USB2 that should be end of lifed in todays consumer markets.

    are arm ready to provide what we the end consumers want to buy (USB3+,fastest IO ports, fastest 3d [MRAM) ram options, etc) or will the oEMs always win favor... providing these in dribs and drabs well after other pratform's have them as options, oh well...
  • JemDavies - Thursday, July 3, 2014 - link

    The Juno platform is not designed to be a performance platform but rather a platform to enable the transition to 64-bit on ARMv8-A targeted to software developers. The Juno boards are simply a small part of a larger amount of work ARM is doing with our developer community today to enable a rapid transition to 64-bit computing. They will only be available to qualified partners and developers.

Log in

Don't have an account? Sign up now