Feature Story

High-End Graphics Have a Travel Itinerary: Conversation with Peter McGuinness, Imagination Technologies

High-end graphics are refusing to stay in high-end devices, instead hitting the road and making themselves at home in everything from doorbells to driver assistance systems to washing machines to printers and beyond.

One of the trends Peter McGuinness, director of multimedia technology marketing, Imagination Technologies, remarked on during his Q&A with EECatalog is that the mobile space is hankering for "what at least looks like and behaves like a smartphone, but does not actually have a real smartphone inside it—so it's high-end graphics." McGuinness has been keeping an eye on the trend of high-end graphics migrating to the low end and on its manifestation as a high-end user interface look. He notes the trend is a factor behind the company's announcements at MWC last month, which saw Imagination announcing a highly optimized, tiny 4-core GPU that brings Imagination's high-end PowerVR Rogue graphics to cost and area-constrained devices such as wearables and IoT.

Following are edited excerpts from our EECatalog Q&A with McGuinness:

EECatalog: What trends are you seeing?

Peter McGuinness, Imagination Technologies: Camera and vision apps are huge, and wearables are starting to come into their own.

The technology that is being driven by these trends [means] we are seeing a lot of always on/always aware devices, and that has an impact on the technology that we have to provide—in particular, things like deep sleep modes so that the awake device can be minimally aware of being woken up—and, when appropriate, progressively woken up so that we can preserve battery life and have a device that lasts for a useful length of time.

Figure 1. McGuinness comments, "…if you compare our selected H.265 bit rate at that selected point, you see that it is achieving just over 20 Mbps for that quality, whereas if you look at the green line (the competition), that same quality results in a bit rate of over 40Mbps." [Image courtesy Imagination Technologies.]

We are going to continue to see large multifunction devices put into cell phones, but we are also going to see diverse development of remote sensors, which will feed into that, and I think that is quite established as a development track.

The GPU compute story is very strong. People are using the GPU, using OpenCL and other programming languages on the GPU to support vision applications and computational photography in handsets and mobile—it's a very strong trend.

EECatalog: What does this trend of high-end graphics making their way to low-end devices mean for the direction Imagination is taking?

McGuinness: We saw a slot in the market for an area optimized GPU [the G6020] that supports OpenGL ES3.0, which is more than is needed today for the minimum OS requirements, but we believe that is the direction the market is moving in anyway. It's beneficial because it gives programmers the same programming model from low- to high-end devices.

The OpenGL ES3.0 API interface is significantly different than the API that came before it, but it's very similar to iterations of API that have come after it, and that is very beneficial when you are developing applications. We made the G6020 GPU very small to address the needs of devices with limited silicon area and bandwidth. And we have optimized it specifically for the use cases that we see as being relevant to this market.

The application space that we are targeting with the G6020 GPU does not require lots and lots of visual effects that demand complex shaders. [For applications that are] user interface oriented, you do have a lot of layers, and you do have blending going on between the pixels. However, you don't need to run the high-precision shaders, and you don't need a lot of geometry transforms.

Some of these applications are entry-level phones, where we are expecting those phones and other equipment to have screen sizes up to 720p. To address this, we size the performance of the device to give it very good, very responsive User Interface (UI) performance at 720p, with a 60Hz refresh rate [so as to achieve] quite a sophisticated user interface. So Android will work well. Chrome OS would also be a very good candidate for this. For some of the higher-end wearables, which have a screen, we can clock it down to meet the necessary power profile.

Tablets and devices with a GUI in the commercial enterprise world are additional examples. Multi-use printers are starting to incorporate quite sophisticated screens. We also seeing applicability for home automation stuff, washing machines and door entry control consoles—to name a few.

And in the automotive world, at the low end, where you have a basic UI, it would be appropriate for that as well.

The characteristics of using the GPU at this level differ (somewhat) from the characteristics needed at the more general level. We [modified] the Unified Shading Cluster (USC) to make it more suitable for pushing pixels, so it has a higher fill rate and is [therefore] more suited to driving a smooth, liquid user interface rather than high-performance 3D graphics.

EECatalog: Imagination announced a High Efficiency Video Coding (HEVC) IP family at MWC—what are the key take aways there?

McGuinness: The promise of [the H.264 and H.265] encode standards are very high compression ratios. Ultra High Definition TV is driving H.265, similarly to how HD drove H.264.

With video compression being the driving factor, we wanted to produce IP that delivers on the promise of H.265. That is, you get 50 percent better bit rate, which is 50 percent better compression in the same format by comparison with H.264.

We saw that earlier introductions by other firms of H.265 encoders don't implement the encoding toolkit in such a way that you get the real promise of H.265. Typically we get a 30 percent lower bitrate at equivalent quality in comparison with the competition. That is a key feature because it is that extra compression which is really going to drive the viability of 4k in consumer and prosumer equipment.

EECatalog: Compare different approaches to implementing the encoding toolkit for H.265.

McGuinness: The competition is implementing less of the encoding toolkit [than we do]. [This approach] means that then they can build a cheaper device, which occupies less silicon area. And of course, it takes less time to design, so they are able to get into the market faster. Those are the driving factors behind their design decisions, but the effect of [those decisions] is to have a mediocre bitrate outcome. In order for the competition to close the gap of bitrate versus quality, they would need to redesign their architecture. [Should they do so] they would lose their time to market advantage and they would lose their area cost advantage.

EECatalog: Where are you finding opportunities to make your whole solution more than just the sum of its parts?

McGuinness: We own the major blocks of the multimedia subsystem, and we have been working over the past few years to make sure that they interoperate in the most efficient fashion. For instance, we have the camera ISP, and we have created a private streaming path between that IP and the video encoder IP so that we have direct IO.

You can capture the image directly from the camera, stream it into the encoder and out through the transmission channel in bitstream form, without the images having to touch DRAM. You give up something in compression, because you are not going to be using B-frames, but you get an enormous power advantage for the application.

The common thrust of all of our IP families is that we have gone for a combination of the highest quality and the lowest possible bitrate because we think that is the real value proposition of H.265 (Figure 1).

EECatalog: What comments do you have from a high-altitude perspective about the IoT?

McGuinness: We work with a lot of people who are creating products for the IoT, and one of their difficulties, and one of the things that we have seen, is that the with first iteration of IoT—and Google Glass is a good example of this—they have taken devices, SoCs, from merchant semiconductor companies, and they have tried to repurpose them to fit the requirements of the IoT.

And so for instance Google Glass, the one that has just been discontinued, has TI OMAP 4 in there, which is a cell phone chip. That repurposing really has not worked because the mobile phone SoCs are a bit of a Swiss army knife, they do a bit of everything, whereas the IoT SoCs need to be (I would not say single-function, exactly) but they need to have a more restricted set of functionality, and they certainly need to be more fine tuned in order to meet the power and cost and actual physical size constraints of the IoT.

So we are seeing a number of companies, a lot of companies in fact, becoming "vertical" in the sense that they want custom SoCs designed for them but they don't see that coming from the merchant semiconductor companies, who have different imperatives.

In response to the pressures of IoT and the absence of specific chips coming from the semico's, companies are coming to us, they are having us work closely with them to design optimized chips, and then they are taking it to a provisioning company, using a foundry. Then they source their own chips directly from the foundry in order to get the fine-tuned, exact chip needed for their market.
Examples include a company called Ineda Systems that is designing a very clever niche space wearables-oriented chip. And a company called Toumaz Group in the UK, which is operating in the medical appliance sphere.

EECatalog: What are the problems that Imagination and others in your market space are wrestling with?

McGuinness: Certainly in the mobile world the big problem that everyone has now with very large devices with many, many millions of transistors, and with Moore's Law driving [us] toward finer and finer geometries, is the problem of dark silicon.

We can put so many transistors on a chip now, and those transistors can be clocked so fast, and hence burn so much energy, that we cannot afford to turn them all on at the same time, so some of the silicon has to be dark at any one time.

And the consensus approach to some of these problems is to look at the high-cost items with regard to power—bandwidth utilization, throughput and the energy per operation.

One of the strengths that Imagination has is that we have all of the major elements needed for our customers to actually produce an SoC. We control all of those elements. So we are able to do things like create a standard compression format that all of those elements can share, so you can compress everything that goes in and out of memory, DRAM, and that reduces power dissipation by an enormous amount.

We are focused on the energy-per-operation of all of the things that we do, [even] focused to the extent that sometimes we irritate our industry collaborators on standards bodies, because we understand well that down to the very low level of implementation detail, it is really important, to use, for instance, the right data quantities, even in your software, in order to get the best energy efficiency.

For example, one of the optimizations that we made for the G6020 computing cluster, the shading cluster, was that instead of having 32-bit floating point throughout, which you can do, we changed the balance, so we've got a bit of 32-bit floating point capability, but the majority is in16-bit, which for that application space where users want a feature phone with a smartphone interface, where you have high-end graphics migrating to the low end in a certain form, is perfectly adequate. For a given operation, by using a 16-bit you reduce the energy required for that operation.

Another example: The OpenCL Embedded Profile from Khronos allows you to have different ways of doing rounding and much lower energy per operation in floating point functions, and that is the profile that we implemented in our GPUs.

The other OpenCL profile from Khronos, the Full Profile, has much higher precision than floating point. It has 64-bit floating point as standard, and is aimed at high-performance computing. It is not aimed at embedded.

We know of one GPU vendor that opted for the Full Profile OpenCL, which made its OpenCL solution unusable because it was too power-hungry. For example, attempts to run an OpenCL app cause the power management software to come in and shut the GPU down because the GPU is gobbling too much power and threatening to destroy the chip.

Return to: 2015 Feature Stories