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.
Neil Trevett's partial map of the messy GPGPU terrain.