Ask the Experts - ARM Fellow Jem Davies Answers Your GPU Questions

99 Comments

View All Comments

• JemDavies - Wednesday, July 2, 2014 - link

  I’m sorry, perhaps I misunderstand the question. Mali-V500 (released last year) supports up to 4k resolutions and up to 120 frames per second (4kp120). We have a multicore architecture. A single core can do up to 1080p60 (depending on silicon process), and by laying down multiple cores (up to 8), the higher frame rates and resolutions can be achieved.

• R3MF - Tuesday, July 1, 2014 - link

  Q - Mali 7xx series - full DX11 compliance or not?
  
  Q - Did Khronos drop the ball on progressing OpenGL ED and force Google to release the "extension pack"?

• JemDavies - Tuesday, July 1, 2014 - link

  Regarding your first question, Mali-7xx supports the DX11 API. Mali-T760 supports Feature Level 11.1 and Mali-T720 supports Feature Level 9.3.
  
  Khronos internal discussions remain confidential (Google is a Khronos member), but no, I don’t think so. I don’t believe I am breaking any confidences by saying that the feature list for OpenGL ES 3.1 was agreed by the parties in Khronos and was obviously the usual compromise between features and schedule. The OpenGL ES 3.1 API was announced as ratified back in March and I don’t think that Google have announced a firm date for the inclusion of the Android Extension Packs yet. All Mali Midgard GPUs will support both Extension Packs.

• R3MF - Thursday, July 3, 2014 - link

  thanks.

• przemo_li - Tuesday, July 1, 2014 - link

  Apple have nicer abstraction layer over GPU. Nvidia have more desktop-like features.
  
  What is selling point of ARM GPUs?
  
  (Also, when will we see OpenGL ES 3.1, and if all 3.0 GPUs will get it)

• JemDavies - Tuesday, July 1, 2014 - link

  Thanks for your comments – it’s always good to hear other viewpoints. We believe the selling point of ARM GPUs is to support the wide range of silicon Partners across the industry, not just a single customer (we have licensed over 55 Partners). We support the features required by our Partners in a power, energy and silicon area-efficient fashion.
  
  ARM have already announced the availability of OpenGL ES 3.1 drivers (they have already passed conformance). Obviously I cannot commit to when our Partners will release them, but I assume they will be competing to get them out there as soon as possible.
  
  The aim of OpenGL ES 3.1 was not to require any new technical features over OpenGL ES3.0, so from a technical standpoint, any GPU that supports OpenGL ES 3.0 should be able to support OpenGL ES 3.1. All ARM Midgard GPUs will support OpenGL ES 3.1.

• przemo_li - Tuesday, July 1, 2014 - link

  I would like to know more about Your GPU licensing mode.
  
  For CPUs its 3-tier approach.
  
  For GPUs its ... ?

• JemDavies - Tuesday, July 1, 2014 - link

  For GPUs, we have a two-pronged roadmap (so far). The two approaches reflect the requirements of our Partners. Those producing so-called superphones are almost inevitably thermally constrained. The actual thermal limit will vary from licensee to licensee depending on their implementation and silicon process, and will vary from OEM to OEM depending on the ability of the case design to dissipate heat (e.g. whether it is an aluminium or plastic case), but for most of these partners, they are looking for the maximum performance within a given power limit (frames per second per Watt)
  
  The other approach is for a large majority of our Partners who are making more mid-range mass-market devices (not just phones, but also tablets, DTV and STB). They care most about cost (equals silicon area). So they want the maximum performance within a silicon area allocation (frames per second per square millimetre).
  
  Of course, everybody cares about cost and everybody cares about power consumption, so it’s not a complete either-or situation. We always try to produce GPUs that are good in both areas, but the two prongs reflect the biggest careabouts for our Partners.

• przemo_li - Wednesday, July 2, 2014 - link

  I was refering to ARM licensing ARM7/ARM8 as instruction sets, basic designs to wrok from for OEMs who want to differentiate, or selling stock designs for those that wish fastest time to market.
  
  For GPUs You generally license just ready made designs?
  (Are 2 other business models empoled by ARM CPU division possible for GPUs?)

• JemDavies - Wednesday, July 2, 2014 - link

  Today, our work is focused on producing ready-made designs that our Partners then configure to suit their needs from a range of options (essentially the same as licensing CPU designs). There is nothing inherent within our architecture that would prevent us from pursuing architectural licenses but it’s not a focus for us in the near term. If this were something we chose to pursue, a GPU architectural license would fundamentally differ from a straight CPU license due to the large software component.