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

Question

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.

Answer 1

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 :-)