Мальчик, это большой предмет.
Сначала я начну с очевидного: поскольку вы вызываете функцию (любую функцию) из ЦП, она должна выполняться хотя бы частично в ЦП. Таким образом, вопрос на самом деле заключается в том, сколько работы выполняется на процессоре и сколько на графическом процессоре.
Во-вторых, для того, чтобы графический процессор мог выполнить какую-либо команду, ЦПУ должен подготовить описание команды для передачи. Минимальный набор здесь - это токен команды, описывающий, что делать, а также данные для выполняемой операции. То, как процессор запускает GPU для выполнения команды, также несколько важно. Поскольку в большинстве случаев это дорого, центральный процессор делает это не часто, а собирает команды в буферах команд и просто отправляет целый буфер для обработки графическим процессором.
Все это говорит о том, что передача работы в GPU не является бесплатным упражнением. Эта стоимость должна быть сопоставлена с запуском функции на процессоре (независимо от того, о чем мы говорим).
Сделав шаг назад, вы должны спросить себя, зачем вам вообще нужен графический процессор. Дело в том, что чистая реализация ЦП выполняет свою работу (как упоминает AshleysBrain). Сила графического процессора заключается в его дизайне для обработки:
- специализированные задачи (растеризация, смешивание, фильтрация текстур, блиттинг, ...)
- сильно параллельные рабочие нагрузки (DeadMG указывает на это в своем ответе), когда ЦП более предназначен для обработки однопоточной работы.
И это руководящие принципы, которым нужно следовать, чтобы решить, что происходит в чипе. Все, что может извлечь из этого пользу, должно работать на GPU. Все остальное должно быть на процессоре.
Кстати, интересно. Некоторые функциональные возможности GL (в основном до устаревания) не очень четко разграничены. Списки отображения являются, вероятно, лучшим примером такой функции. Каждый драйвер может свободно выдвигать столько, сколько ему нужно, из потока списка отображения в графический процессор (обычно в некоторой форме буфера команд) для последующего выполнения, пока сохраняется семантика списков отображения GL (а это несколько хард в общем). Таким образом, некоторые реализации выбирают только передачу ограниченного подмножества вызовов в списке отображения в вычисляемый формат и просто воспроизводят остальную часть потока команд на CPU.
Выбор - это еще один вариант, в котором неясно, имеет ли смысл выполнение на GPU.
И, наконец, я должен сказать, что в целом существует небольшая корреляция между вызовами API и объемом работы на процессоре или графическом процессоре. API установки состояния имеет тенденцию изменять только структуру где-то в данных драйвера. Его эффект виден только при вызове Draw или чего-то подобного.
Многие из GL API работают так. В этот момент спрашивать, выполняется ли glEnable(GL_BLEND) на процессоре или графическом процессоре, довольно бессмысленно. Важно то, произойдет ли смешивание на GPU при вызове Draw. Таким образом, в этом смысле Большинство GL точек входа вообще не ускоряются.
Я мог бы также немного расширить передачу данных, но Данвил коснулся этого.
Я закончу с небольшим "з / ш путь". Исторически, GL должен был работать над спецификацией, независимо от того, какие аппаратные особые случаи были. Это означало, что если h / w не обрабатывал определенную функцию GL, то он должен был эмулировать ее или полностью реализовать в программном обеспечении. Есть множество случаев этого, но один, который поразил многих людей, это когда GLSL начал появляться.
Поскольку не было никакого практического способа оценить размер кода шейдера GLSL, было решено, что GL должен был принять любую длину шейдера как допустимую. Смысл был довольно ясен: либо реализовать ч / б, которые могли бы принимать шейдеры произвольной длины - нереалистичные в то время, либо внедрить эмуляцию ш / ш шейдеров (или, как решили некоторые производители, просто не соответствовать друг другу). Таким образом, если вы вызвали это условие на фрагментном шейдере, есть вероятность, что целом вашего GL в конечном итоге будет выполнено на процессоре, даже если у вас неактивный графический процессор, по крайней мере для этого отрисовки.