Какие функции OpenGL не ускоряются GPU?
Я был потрясен, когда я считал это (из Wiki OpenGL):
glTranslate, glRotate, glScale
Они аппаратно ускорены?
Нет, нет никаких известных GPU, которые выполняют это. Драйвер вычисляет матрицу на ЦП и загружает его на GPU.
Все другие операции над матрицей сделаны на ЦП также: glPushMatrix, glPopMatrix, glLoadIdentity, glFrustum, glOrtho.
Это - причина, почему эти функции считают устаревшими в GL 3.0. Вы должны иметь свою собственную математическую библиотеку, создать Вашу собственную матрицу, загрузить Вашу матрицу на программу построения теней.
Для очень, очень долгое время я думал, что большинство функций OpenGL использует GPU, чтобы сделать вычисление. Я не уверен, является ли это распространенным заблуждением, но через некоторое время взглядов, это имеет смысл. Старые функции OpenGL (2.x и более старый) действительно не подходят для реальных приложений, из-за слишком многих переключателей состояния.
Это заставляет меня понять, что, возможно, много функций OpenGL не используют GPU вообще.
Так, вопрос:
Какие вызовы функции OpenGL не используют GPU?
Я верю знанию, что ответ на вышеупомянутый вопрос помог бы мне стать лучшим программистом с OpenGL. Совместно используйте часть своего понимания.
Править:
Я знаю, что этот вопрос легко приводит к уровню оптимизации. Это хорошо, но это не намерение этого вопроса.
Если кто-либо знает ряд функций GL на определенной популярной реализации (как предложенный AshleysBrain, nVidia/ATI, и возможно зависимый от операционной системы), которые не используют GPU, это - то, что я после!
Вероятные руководства по оптимизации появляются позже. Давайте сфокусируемся на функциях для этой темы.
Edit2:
Эта тема не о том, как работают матричные преобразования. Существует другое темы для этого.
5 ответов
Мальчик, это важный предмет.
Во-первых, я начну с очевидного: поскольку вы вызываете функцию (любую функцию) из ЦП, она должна хотя бы частично выполняться на ЦП. Так что вопрос действительно в том, какая часть работы выполняется процессором, а какая - графическим процессором.
Во-вторых, для того, чтобы GPU мог выполнить некоторую команду, CPU должен подготовить описание команды для передачи. Минимальный набор здесь - это токен команды, описывающий, что делать, а также данные для операции, которая должна быть выполнена. Также в некоторой степени важно, как ЦП запускает графический процессор для выполнения команды. Поскольку в большинстве случаев это дорого, ЦП делает это нечасто, а пакетирует команды в буферы команд и просто отправляет весь буфер для обработки графическим процессором.
Все это означает, что передача работы графическому процессору не является бесплатным занятием. Эту стоимость нужно противопоставить простому запуску функции на ЦП (неважно, о чем мы говорим).
Сделав шаг назад, вы должны спросить себя, зачем вам вообще нужен графический процессор.Дело в том, что эту работу выполняет чистая реализация ЦП (как упоминает AshleysBrain). Мощь графического процессора проистекает из его дизайна для решения:
- специализированных задач (растеризация, смешивание, фильтрация текстур, блиттинг, ...)
- тяжелых параллельных рабочих нагрузок (DeadMG указывает на это в своем ответе), когда ЦП больше предназначен для обработки однопоточной работы.
И это руководящие принципы, которым нужно следовать, чтобы решить, что входит в микросхему. Все, что может извлечь из этого выгоду, должно работать на графическом процессоре. Все остальное должно быть на процессоре.
Это, кстати, интересно. Некоторые функциональные возможности GL (в основном до прекращения поддержки) действительно четко не определены. Списки отображения, вероятно, лучший пример такой функции. Каждый драйвер может передавать столько, сколько он хочет из потока списка отображения в графический процессор (обычно в некоторой форме буфера команд) для последующего выполнения, пока сохраняется семантика списков отображения GL (а это в некоторой степени ] жесткий в целом). Таким образом, некоторые реализации предпочитают передавать только ограниченное подмножество вызовов в списке отображения в вычисляемый формат и просто воспроизводить остальную часть потока команд на ЦП.
Selection - это еще один вариант, когда неясно, есть ли смысл в выполнении на GPU.
Наконец, я должен сказать, что в целом существует небольшая корреляция между вызовами API и объемом работы ЦП или ГП. API настройки состояния имеет тенденцию только изменять структуру где-то в данных драйвера. Его эффект виден только при вызове Draw или чего-то подобного.
Многие API GL работают так. В этот момент спрашивать, выполняется ли glEnable (GL_BLEND) на CPU или GPU, бессмысленно. Важно то, будет ли смешивание происходить на графическом процессоре при вызове Draw. Таким образом, в этом смысле Большинство точек входа в GL вообще не ускоряются.
Я мог бы также немного рассказать о передаче данных, но Данвил коснулся этого.
Я закончу маленьким "з / б путём". Исторически GL должна была работать в соответствии со спецификациями, независимо от того, каковы были особые случаи оборудования. Это означало, что если аппаратное обеспечение не обрабатывало конкретную функцию GL, то ему приходилось эмулировать ее или реализовывать полностью в программном обеспечении. Случаев тому множество, но многих поразило то, что GLSL начал появляться.
Поскольку не было практического способа оценить размер кода шейдера GLSL, было решено, что GL должен принимать любую длину шейдера как допустимую. Смысл был довольно ясным: либо реализовать h / w, которое могло бы принимать шейдеры произвольной длины, что в то время было нереалистично, либо реализовать эмуляцию шейдера s / w (или, как решили некоторые поставщики, просто не соответствовать требованиям). Итак, если вы запустили это условие для фрагментного шейдера, скорее всего, все целое вашего GL в конечном итоге выполнялось на CPU, даже когда у вас был простаивающий графический процессор, по крайней мере, для этого отрисовки.
Существуют программные реализации OpenGL, поэтому вполне возможно, что нет функций OpenGL, работающих на графическом процессоре. Также есть оборудование, которое не поддерживает определенные состояния рендеринга на оборудовании, поэтому, если вы установите определенное состояние, переключитесь на программный рендеринг, и снова ничего не будет работать на графическом процессоре (даже если он там есть). Поэтому я не думаю, что существует четкое различие между «функциями с ускорением на GPU» и «функциями, не ускоренными с помощью GPU».
На всякий случай старайтесь делать вещи как можно проще. Простой рендеринг с вершинами и базовые функции, такие как Z-буферизация, , скорее всего, будут аппаратно ускорены, поэтому, если вы сможете придерживаться этого с минимальным изменением состояния, вы, скорее всего, сохраните аппаратное обеспечение. ускоренный. Это также способ максимизировать производительность рендеринга с аппаратным ускорением - видеокарты любят оставаться в одном состоянии и просто обрабатывают кучу вершин.
glTranslate, glRotate и glScale изменяют текущий матрица активного преобразования. Это, конечно, операция ЦП. Матрицы вида и проекции модели просто описывают, как графический процессор должен преобразовывать вершины при выдаче команды рендеринга.
Так, например, вызовом glTranslate еще ничего не переведено. Перед рендерингом матрицы текущей проекции и вида модели умножаются (MVP = проекция * вид модели), затем эта единственная матрица копируется в графический процессор, а затем графический процессор выполняет умножение матрицы на вершину («T&L») для каждой вершины. Таким образом, перемещение / масштабирование / проекция вершин выполняется графическим процессором.
Также вам действительно не стоит беспокоиться о производительности, если вы не используете эти функции где-то во внутреннем цикле. glTranslate приводит к трем добавкам. glScale и glRotate немного сложнее.
Я советую вам узнать немного больше о линейной алгебре. Это важно для работы с 3D API.
Обычно, если операция относится к чему-то, она выполняется на графическом процессоре. Примером является реальное преобразование - оно выполняется один раз для каждой вершины. С другой стороны, если это происходит только один раз за большую операцию, это будет на ЦП - например, создание матрицы преобразования, которая выполняется только один раз при каждом изменении состояния объекта или один раз за кадр.
Это просто общий ответ, и некоторые функции будут реализованы наоборот, а также будут зависеть от реализации. Однако, как правило, для вас, программиста, это не имеет значения. Пока вы даете графическому процессору достаточно времени для выполнения своей работы, пока вы занимаетесь симулятором игры или что-то еще, или у вас есть надежная потоковая модель, вам не нужно сильно об этом беспокоиться.
@sending data to GPU: Насколько я знаю (использовал только Direct3D), все это делается в шейдерах, для этого и нужны шейдеры.
Возможно, следует задать вопрос: «Какие функции потребляют неожиданно много процессорного времени?»
Хранение стека матриц для проецирования и просмотра - это не то, с чем графический процессор может справиться лучше, чем процессор (наоборот ...). Другой пример - компиляция шейдера. Почему это должно работать на графическом процессоре? Есть синтаксический анализатор, компилятор ..., которые представляют собой обычные программы ЦП, такие как компилятор C ++.
Потенциально «опасными» вызовами функций являются, например, glReadPixels , потому что данные могут быть скопированы из памяти хоста (= CPU) в память устройства (= GPU) по ограниченной шине. В эту категорию также входят такие функции, как glTexImage_D или glBufferData .
В общем, если вы хотите узнать, сколько процессорного времени потребляет вызов OpenGL, постарайтесь понять его функциональность. И остерегайтесь всех функций, которые копируют данные с хоста на устройство и обратно!