Информация о том, какие тройки вершин образуют треугольники, поступает только на следующий этап конвейера, носящий название «сборка треугольников» (triangle setup). После этого уже можно определить, какие треугольники будут не видны на экране. Независимым исследованием вершин этого установить нельзя: три выходящие за границы экрана вершины могут сформировать частично видимый треугольник. Полностью скрытые треугольники удаляются, чтобы больше не отнимать на себя ресурсов. От частично видимых треугольников отсекаются ненужные части.
На этапе растеризации треугольники разбиваются на множество фрагментов, каждый из которых соответствует одному пикселу экрана, накрываемому треугольником. Здесь же происходит еще одна важная операция — линейная интерполяция значений из вершин треугольника в соответствии с положением фрагмента. После этого обработка каждого фрагмента может происходить автономно от других фрагментов.
В конечном результате для каждого фрагмента необходимо определить его итоговый цвет и, возможно, изменившуюся глубину. Для чего часто требуется доступ к хранящимся в видеопамяти текстурам, которые могут содержать как непосредственно цвет, так и освещенность, отражательную способность или карту неровностей. Доступ к текстурам осуществляется через блок выборки (fetch), который может вернуть цвет текстуры в произвольной точке, а также может выполнять билинейную или анизотропную фильтрацию.
О фрагментах следует думать как о пре-пикселах. Окончательное значение цвета на экране формируется в результате композиции цвета фрагмента с цветом, уже находящимся в экранном буфере, только частным случаем которой является полное замещение. Фрагмент на этом этапе может быть вообще отвергнут, если не пройдет один из тестов, например тест глубины или величины альфа-канала.
Свое окончание конвейер находит в экранном буфере или текстуре, его заменяющей, при включении специального режима render-to-texture. Это единственное место в конвейере, которое доступно приложению для обратного считывания (read back).
Как же использовать графический конвейер не только для отображения трехмерных сцен? Еще относительно недавно нужно было обладать незаурядными знаниями всех операций, которые производители «зашили» в графический чип, чтобы заметить задачу, сводимую к рисованию некоторой сцены. В любом случае, способностей GPU хватало лишь на очень узкий круг вычислительных проблем[Не хочется задерживаться на этой теме, но чтобы не быть голословным, привожу одну из ссылок, где есть программа построения диаграммы Вороного], как правило, не слишком требовательных к точности результата. Но с наступлением нового тысячелетия ситуация начала мало-помалу меняться.
Прежде программирование графики можно было отнести к декларативному типу. Трехмерное приложение перечисляло все объекты в сцене, свойства их поверхностей, говорило, где расположены источники освещения, куда смотрит камера и т. п. В завершение следовала команда графической плате: «А теперь возьми и отобрази, что видит камера!» Эта ситуация была бы всем хороша в спокойные времена, но не когда производители игр отчаянно борются за внимание пользователей, которое, по их мнению, можно привлечь только новыми и желательно уникальными эффектами. Поэтому наметился постепенный переход к императивной парадигме программирования графики. То есть вместо выбора одного из предопределенных типов обработки данных производители игр получили возможность самостоятельно писать малюсенькие программки, непосредственно выполняемые графическим процессором. В первую очередь это затронуло блок обработки вершин, а затем и фрагментов (обведены оранжевым цветом на рис. 1). Поскольку главным образом под эффектами понималась более точная передача игры света и тени, то программки эти стали называть шейдерами (от англ. shade — тень), соответственно разделяя их на вершинные и пиксельные. Появились специализированные низкоуровневые ассемблеры.