# How to estimate what GPU (2D/3D/none at all?) is necessary?

I have to do some operations on 2D grayscale images. The "normal" stuff like moving, alpha blending and resizing, but also "3D like" operations: Perspective projection, rotation around any axis (x, y, z).
All this happens in an embedded system, where I can choose from microcontrollers with "2D GPU" (e.g. Vivante GC355), "3D GPU" (Vivante GC3000), "no GPU" (Arm A53).

Safe approach: Take the 3D GPU and use OpenGL operations (e.g. "Rotate") to do the jobs.

But how can I find out the minimum requirements? In case of the "no GPU" approach it's quite easy to estimate the CPU cycles for each operation and extrapolate.
How to do this for a GPU? The specifications say things like "x million pixels per second" - but what can it do to these pixels in that second? The tutorials I found so far say nothing about it.

• Hmm according to a link here, you can rotate images through openVG api using the 2D GPU to achieve effects like cover flow animation. embedded.com/design/real-world-applications/4410726/2/… – gallickgunner Jun 28 '18 at 15:19
• OpenVG is pretty dead though. I don't think anyone is supporting it any more. – Dan Hulme Jun 28 '18 at 15:27
• @wandering-warrior: Thank you for the link! I haven't found something like this before. It's surely a good starting point for diving deeper into all this strange stuff :-) – mic Jun 28 '18 at 15:31
• @Dan Hulme: You may be right, but if it can be comfortably done using 2D, and that micro is some Cents cheaper, this will be an argument nobody would dare to disagree. Not in this business :-) – mic Jun 28 '18 at 15:41

There are really two things you need to know about your application:

1. How many pixels do you need to push per second?
2. How many cycles do you need to spend on each?

For the first, you need to sum the size of your output framebuffer and all the intermediates to count the number of pixels written in each frame. Make sure to include overdraw: if you draw a full-screen background, and then draw a foreground that covers half of the frame, you need to multiply by $1.5$. Then just divide that by your frame time (e.g. 33 ms if you need to reach 30 fps) to count the pixels per second.

To count cycles, you need to know what size of program will be run on each pixel. For a transformation or colour correction, it might just be a couple of multiply-adds. Somebody who would write the shader code (or the Neon code in the no-GPU case) should be able to work this out for you. It'll be easier if you have a prototype running on a desktop GPU already.

There are also two important properties of the hardware to consider. First is the pixel fill rate, which you've already seen. This tends to be limited by the memory bandwidth of the system-on-chip instead of by the CPU or GPU itself. If you're buying GPU IP and integrating it into the chip itself, you'll need to talk to the vendor's application support people to find out what your design can achieve. If you're buying a whole system-on-chip, just use the value from the spec sheet.

Second is your cycle budget. This depends on the GPU or FPU itself, not on the memory bandwidth, so it's easier to calculate. You just need to talk to the silicon vendor to determine this. For a GPU it'll be the number of cores times the clock speed divided by the instruction cycles per clock - but more realistically, look at a synthetic benchmark for this chip to see its megaflops.

Comparing your number of pixels per second with what the system can achieve is easy, but you also need to multiply this by the cycles per pixel you want to spend, to get the total number of cycles per second you need, and compare this with what the compute core offers.

Don't forget you also need to weigh the difference in BOM cost and software complexity against the risk and cost of a board respin, and multiply your estimate by some fudge factor appropriate to your project risk. We can't help you with that part here :-)

• I think he is more interested in the list of tasks a 3D GPU can perform that a 2D one can't. Based on that he wants to select whether to choose the 2D or 3D Gpu. – gallickgunner Jun 29 '18 at 2:14
• @wandering-warrior: Actually I'd like to understand what a GPU does when I say, for instance, "rotate object x by y degrees around the z axis". I can write an algorithm based on trigonometric functions for a CPU, but how does this compare to that highly sophisticated stuff they implement in a GPU? I, as just a user of APIs (be it OpenVG or OpenGL or whatever) don't know whether the rotation mentioned above needs 1MFlops, or 10, or 0.1 or whatever. – mic Jul 3 '18 at 9:55
• @mic- that's somewhat difficult to answer. I thought you were doing this yourself though. I don't know much about embedded GPUs but you might wanna search for graphics pipeline on the wiki. On modern GPUs we have shaders and this rotation part is usually handled by the vertex shader stage of the graphics pipeline where you multiply the vertices (in the form of a vector) with a Rotation matrix. So it's essentially a vector-matrix multiplication for every vertex you have. – gallickgunner Jul 4 '18 at 3:14
• @wandering-warrior: I wish I had some more experience in this. I just got the task to find a "suitable" Microcontroller to do all this stuff. I'm a little bit surprised that no benchmarks seem to exist which cover examples like mine. Bullet points like "one trillion triangles per second" may be fine for the expert, but surely not for the beginner, respectively the user looking at this from a higher application level. – mic Jul 6 '18 at 8:21
• @mic Integrating a GPU is not really a beginner task. You really need help from whoever will be writing the software to know the performance needs. – Dan Hulme Jul 6 '18 at 8:45