Muddy mobile graphics waters dead ahead

SAN JOSE – 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 (let alone a tech reporter like moi) 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.