# How does a GPU process a task by using multiple ALUs?

I know the philosophy of how a GPU works {many weak men doing a task (GPU) compared to one strong man doing the same task (CPU)}.

How does the GPU manage all the ALUs and schedule the necessary calculation to an ALU?

• This is going to delve into the core (proprietary) design of the gpu. Also the ALU isn't the magic component (it only does integral math) but the FPU is. – ratchet freak Jun 15 '16 at 20:39
• Im trying to build a simple gpu on an fpga that only joins multiple points in 3d space and diplays it on a screen. Im using fixed point operations only. – Karan Jun 15 '16 at 20:48

# Architecture Background

GPU don't schedule to individual ALUs, but rather groups of them. Terminology will vary based on GPU company (NVidia, ATI, and Intel), but I will stick with NVidia terminology since they all work somewhat similarly at the high level.

NVidia has a concept of CUDA cores, each of which contains an ALU and/or FPU, which make up collections called Streaming Multiprocessors (SM). The Fermi architecture has 32 CUDA cores per SM, for example.

GPUs operate in a SIMD-like manner. This means that unlike a CPU, which traditionally has had one execution unit per instruction, GPUs have many execution units per instruction (CUDA core). These groups of execution are called warps.

GPUs contain scheduling units that attempt to reach maximal utilization. Warps are scheduled in a way to utilize as much of the GPU as possible. One way to do this is to use a round-robin approach. Latency is something that a GPU struggles with compared to a CPU, so scheduling a process as soon as possible is often desirable. Like an OS (which controls CPU scheduling), however, simplicity and hiding latency are still desirable traits to an extent, although other tradeoffs may be deemed more important.

Your workload will determine how scheduling is done. If you run a CUDA kernel or shader on 320 pieces of data (threads), you will need at least 10 warps to be scheduled (this depends on the type of data as well). If you have 1 thread that needs to be calculated, oh well, you still need to schedule one warp to do the calculation.

Of course, what ratchet freak said is true about GPU architectures and algorithms being proprietary, especially when compared to CPUs.

Maybe you need to write down the spec of what you want to do first, usually when you know the problem you know the solution. So mostly, life is a matter of finding the problems.

I believe in your case, what you want to do is replicate what GPUs were in 1996, that is, a brute force texture filler specialized hardware.

GPUs did nothing back then, no vertex transform, no 3d, they just took regions in 2d (triangles after projection) and filled them. The only 3d-like operation that the hardware could do, was the division by w during rasterization. Pretty handy to have dedicated hardware to do that, since CPUs suck at this.

So, if you want to do wireframe, basically your hardware will be a bresenham implementation but in FPGA. Are you sure this makes any sense?
Bresenham parallelization will be an interesting job though, you can split your space into screen tiles and do grid-scheduling (eg ALU[i], i = pixelX / 32 % numalu for 32 pixel wide tiles). You'll need to clip your lines to the tiles borders.

Though it seems to me that your biggest challenge will be to convert your frontbuffer to display port protocol. Or VGA if you still have that. maybe some ready to use chips exist for that (or FPGA schemas that you can load and append to your design?).