Muddy mobile graphics waters dead ahead

April 19, 2012 //
By 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