처리 파이프라인 설계하기

A real image pipeline is a chain of stages: load, blur, sharpen, color-correct, save. Each stage is one clear transformation you can reason about alone. 🧩

Pixels move forward through the pipeline: each stage reads the previous output and produces the next input. This one-way data flow keeps the design simple to follow.

Between two stages you need a place to park pixels. A buffer is just a device array that one kernel writes and the next kernel reads. Plan a buffer per boundary.

You rarely need a fresh buffer per stage. Ping-pong between two buffers: read from one, write to the other, then swap. Two buffers serve a whole chain.

Start with one kernel per stage. It is the clearest design and the easiest to verify. You will fuse stages later once each one is correct.

The natural mapping is one thread per pixel. A 2D grid covers width and height, so each thread owns exactly one (x, y) location to process.

Images are stored row by row. Turn (x, y) into a flat offset with row-major indexing so every thread reads the right pixel.

Your grid is rounded up, so some threads fall outside the image. A simple bounds check keeps them from touching memory they should not.

A block like 16x16 or 32x8 gives good coverage and warp-friendly rows. Pick a 2D block shape that divides the image cleanly when you can.

Allocating device memory is costly, so do it once before the loop. Reuse the same buffers for every frame instead of malloc and free each time.

Draw the stages, their buffers, and the arrows between them first. A clear diagram of data flow catches design mistakes long before any kernel runs. ✏️

You have a chain of stages. How do you avoid allocating a new buffer for every stage?

You designed a pipeline as one-way stages joined by buffers, mapped one thread per pixel with a 2D grid, and learned to ping-pong buffers and sketch the flow first. 🎯