Print  |  Send  |   

Muddy mobile graphics waters dead ahead

April 19, 2012 // Rick Merritt

Muddy mobile graphics waters dead ahead

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.

Page 1 of 1

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 theres 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. Apples latest iPad showed that mobile design these days is all about the graphics and what they can deliver in display and photo resolution.

So whats 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. Thats Tims 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 whos 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 lets 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 iswait a minute, Im 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 choicesand 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, its 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.

Theres a chicken-and-egg problem here. Mobile chip makers wont want to spend the energy and gates to support DX11 until there are apps that take advantage of itand vice versa. Poor Microsoft, just cant seem to get ahead of the Apple and Android pack in mobile!

Meanwhile, as if reality itself isnt 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 Googles Project Glass, however, is probably still five years away, said Trevett.

Separately, theres all sorts of work afootsuch as the Khronos WebGL and WebCL initiatives--to bring all this graphics goodness to developers 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 Qualcomms Leland also reminded me why its 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.


All news

Wireless Comms,RF & Microwave,Displays & Interfaces

Follow us

Fast, Accurate & Relevant for Design Engineers only!

Technical papers     

Linear video channel


Read more

This month Ambiq Micro is giving away five of its 'Apollo EVB' evaluation boards, worth 9 each for EETimes Europe’s readers to assess the capabilities of their cutting-edge Apollo sub-threshold microcontroller.

The new suite of Apollo MCUs is based on the 32-bit ARM Cortex-M4 floating point microcontroller and redefines 'low power' with energy consumption that is typically five to...


Design centers     

Infotainment Making HDTV in the car reliable and secure

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.


You must be logged in to view this page

Login here :