how does a graphics pipeline work

your video card has, in its memory, a detailed model of everything going on it might need to render. things like vertices, textures, etc. the graphics pipeline is the process in which these abstract data points are converted into 2D pixel maps to be clocked out via the phase lock loops & CRTCs

the thing is, this needs to happen very quickly. some numbers:

my monitor has a resolution of 1920 x 1200. this means it’s 1920 pixels wide and 1200 pixels long. 1920*1200 = 2304000 pixels i need to account for

each pixel has a red, green, and blue value each between 0 and 255. numbers in this range can be expressed via an eight bit number (one byte). so:

2304000 * (1 byte per color * 3 colors) = 6912000 bytes per rendered frame.

lets use a standard frames-per-second of 60, 6912000 bytes * 60 frames/second = 414.72MB of data going from your video card -> monitor every second. wow!

so the graphics pipeline involves transcribing the vert/texture/lighting/AA values from video RAM to the scan-out buffers in a way quick enough to maintain a steady frame rate that appears fluid to a human

we pipeline this process, which means we cut it up into a handful of chunks, and have each chunk active at once. the vert/texture/whatever information goes into the first stage, and is processed into the second. the next set of data is immediately loaded into the first stage registers once the initial data set has left it

CPUs do this too, and their pipelining is much more easily understood. in a MIPS CPU (for example), first you fetch the instruction from RAM, decode it, execute it, write or read any values from memory implicated by the instruction (if any) and finally increment or change outright the PC counter