Muddy mobile graphics waters dead ahead

April 19, 2012 // Rick Merritt

Tim Leland, the guy I think of as Mr. Graphics at Qualcomm, pulled me aside as I was leaving the Linley Tech Mobile Conference yesterday. He wanted to make sure I understood that a core is not a core when it comes to graphics.

When it comes to mobile SoCs generally chips with two CPU cores are better than those with one, four cores are better than two, and so on. But not so with the GPU.

What Qualcomm calls a graphics core is different from what Nvidia or someone else calls a GPU core, he said. So when Huawei boasted at Mobile World Congress this year its K3V2 mobile SoC with 16 Vivante GPU cores will blow away the competition, well, take it with a grain of salt, Leland said.

The problem is there’s no clean way to compare graphics performance which is rapidly becoming the center of competition in mobile systems. Indeed the graphics part of mobile SoCs is growing faster than any other part of the chip. Apple’s latest iPad showed that mobile design these days is all about the graphics and what they can deliver in display and photo resolution.

So what’s an OEM to do? Hire a grad student to sort through the dozen or so relevant graphics benchmarks, run them on all the key chips and do a multivariate analysis of the results. That’s Tim’s advice anyway.

I translate it this way: Duck! I see a few years of marketing head spin dead ahead as we try to sort out who’s leading the manic mobile market in its pursuit of triangles per second--which by the way is not a good single benchmark either!

Unfortunately the darkness gets even deeper. The next big thing in graphics is using these massively parallel chips to handle naturally parallel applications of all sorts such as media processing. The reason you can do this is that the GPU “cores” are made up of sometimes thousands of sub-cores, but let’s not go there.

Luckily, programmers do not have to understand all the details of the hundreds of sub-cores inside a graphics core. They can just use an API such as OpenCL from Khronos, or Cuda from Nvidia or AMP from Microsoft or River Trail from Intel or Aparapi from AMD or Renderscript from Google or OpenACC which is related to OpenMP which is…wait a minute, I’m lost!

Stirring the pot, OpenCL itself is splitting into a high-level API for programmers and a low level one for chip designers. This makes sense, but adds to the seeming confusion for the outsider. Oh, and the core OpenCL spec will probably see a new rev in 2013.

At the Linley Tech conference, API guru Neil Trevett showed one packed slide that tried to lay out all the options in APIs for doing general-purpose processing on a GPU. It was messy.

Ever the optimist, Trevett hopes the high-level APIs adding extensions to C++ or Javascript will “meet in the middle” with low level APIs like OpenCL and Cuda coming from the silicon up. The good news is, developers have choices…and they may need to hire a second grad student to help sort through them.



  Neil Trevett's partial map of the messy GPGPU terrain.


By the way, now that the OpenGL ES 2.0 standard for accelerating mobile graphics is being used everywhere, it’s time for version 3.0. Expect whatever features this new rev defines to become the new battleground in mobile GPU cores. Trevett would only say the 3.0 update is “coming soon.”

Microsoft could get ahead of the mobile graphics game because Windows 8 on ARM (now called Windows RT) supports the relatively advanced and mature DirectX APIs Microsoft uses on PCs. Only trouble is none of the three mobile SoCs that Microsoft supports with Win RT support DX11. Instead, they support, through a kludge more generally called “a shim” the older DX9 APIs.

There’s a chicken-and-egg problem here. Mobile chip makers won’t want to spend the energy and gates to support DX11 until there are apps that take advantage of it—and vice versa. Poor Microsoft, just can’t seem to get ahead of the Apple and Android pack in mobile!

Meanwhile, as if reality itself isn’t weird enough, augmented reality is coming.

Khronos is helping create some of the silicon plumbing for the merger of the physical and the digital/virtual worlds with work on its media streaming API and a new API for sensor fusion coming later this year. The display technology for powering augmented reality products like Google’s Project Glass, however, is probably still five years away, said Trevett.

Separately, there’s all sorts of work afoot—such as the Khronos WebGL and WebCL initiatives--to bring all this graphics goodness to developer’s working in Javascript for programs that run in a browser. The broader HTML 5 standard “could be one of the most significant programming advances we make in the next few years” for enabling browser-based apps with near-native performance, Trevett said, pointing to a Khronos-sponsored conference on the topic.

So I feel I really need to understand graphics better. But Qualcomm’s Leland also reminded me why it’s hard to get a good graphics education.

Graphics companies have been slapped with suits citing trade journal articles where their execs described the allegedly infringing features in their chips. It takes big money to make such suits go away. That explains why I almost never get pitched about in-depth technical briefings on graphics.

Technical papers     

• High Voltage Surge Stoppers Ensure Reliable Operation During Power Surges
• AR RF/Microwave Instrumentation Field Analyzers
• 16-Bit, 100 kSPS Low Power Successive Approximation ADC System
• Replacing the Candle in the Candelabra

December 15, 2011 | Texas instruments | 222901974

Unique Ser/Des technology supports encrypted video and audio content with full duplex bi-directional control channel over a single wire interface.