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.
Neil Trevett's partial map of the messy GPGPU terrain.
OpenGL ES is widely supported in mobile SoCs now. My understanding is engineers are just starting to support OpenCL for general-purpose GPU computing on the mobile chips with Qualcomm among the leaders here, hoping to run imaging apps in its Adreno graphics using OpenCL. Others are expected to follow, but the trend is just beginning in mobile
Interesting story. You mention "The next big thing in graphics is using these massively parallel chips to handle naturally parallel applications of all sorts such as media processing." and go on to talk about programmers using CUDA or OpenCL etc. to program the graphics cores within mobile SoCs. Later you mention the OpenGL ES 2.0 API for programming these devices.
Isn't it the case at the moment that OpenGL is the only way to program the graphics cores within mobile SoCs? I'm not aware of any official plans from any SoC vendors to provide more general purpose programmatic access (CUDA/OpenCL/etc.) to the graphics cores within the mobile SoCs, do you know of any such plans?
I actually believe it will be a period of rapid innovation - but it will be very competitive and there are going to be some that lose big.
The 2D graphic wars of the early 90's, desktop 3D wars, and now a new one with much higher potential volume but very constrained cost and power.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.