Какие функции OpenGL не ускорены GPU?

Ответ 1

Мальчик, это большой вопрос.

Во-первых, я начну с очевидного: поскольку вы вызываете функцию (любую функцию) из CPU, она должна запускаться хотя бы частично на CPU. Так что на самом деле вопрос в том, какая часть работы делается на процессоре и сколько на графическом процессоре.

Во-вторых, для того, чтобы GPU мог выполнить некоторую команду, CPU должен подготовить описание команды для передачи. Минимальный набор здесь - это токен команды, описывающий, что делать, а также данные для выполняемой операции. То, как CPU запускает GPU для выполнения команды, также несколько важен. Поскольку большую часть времени это дорого, CPU не делает этого часто, а скорее выполняет команды в командных буферах и просто отправляет весь буфер для обработки графического процессора.

Все это говорит о том, что передача работы на GPU не является бесплатным упражнением. Эта стоимость должна быть противопоставлена ​​простому выполнению функции на CPU (независимо от того, о чем мы говорим).

Сделав шаг назад, вы должны спросить себя, зачем вам нужен GPU. Дело в том, что чистая реализация ЦП выполняет эту работу (как упоминает AshleysBrain). Мощность графического процессора зависит от его конструкции:

• специализированные задачи (растеризация, смешивание, фильтрация текстур, блиты,...)
• сильно параллельные рабочие нагрузки (DeadMG указывает на это в его ответе), когда процессор больше предназначен для обработки однопоточной работы.

И это основные принципы, которым нужно следовать, чтобы решить, что происходит в чипе. Все, что может выиграть от них, должно выполняться на графическом процессоре. Все остальное должно быть на процессоре.

Это интересно, кстати. Некоторые функциональные возможности GL (до того, как они были отменены, в основном), на самом деле четко не очерчены. Отображаемые списки, вероятно, являются лучшим примером такой функции. Каждый драйвер может нажимать столько же, сколько требуется, из потока списка отображения на GPU (обычно в некоторой форме буфера команд) для последующего выполнения, если сохраняется семантика списков отображения GL (и это несколько сложно Генеральная). Таким образом, некоторые реализации выбирают только для того, чтобы подтолкнуть ограниченное подмножество вызовов в списке отображения к вычисленному формату и выбрать просто воспроизвести остальную часть потока команд на ЦП.

Выбор другой, где неясно, есть ли значение для выполнения на графическом процессоре.

Наконец, я должен сказать, что в целом существует небольшая корреляция между вызовами API и объемом работы либо с процессором, либо с графическим процессором. API настройки состояния имеет тенденцию только модифицировать структуру где-нибудь в данных драйвера. Эффект отображается только тогда, когда вызывается Draw или какой-либо такой.

Много API GL работает так. В этот момент вопрос о том, выполняется ли glEnable(GL_BLEND) на CPU или GPU, не имеет смысла. Важно то, произойдет ли смешение на GPU при вызове Draw. Итак, в этом смысле большинство точек входа GL не ускоряются вообще.

Я мог бы также немного расширять передачу данных, но Дэнвилл коснулся его.

Я закончил с небольшим "s/w path". Исторически GL должен был работать, чтобы специфицировать, какими бы ни были аппаратные специальные случаи. Это означало, что если h/w не обрабатывал конкретную функцию GL, тогда она должна была эмулировать ее или полностью реализовать в программном обеспечении. Есть много случаев этого, но тот, который поразил многих людей, - это когда GLSL начал появляться.

Поскольку не было никакого практического способа оценить размер кода шейдера GLSL, было решено, что GL должен был принимать любую длину шейдера как действительную. Импликации были достаточно ясными: либо реализовать h/w, которые могут принимать произвольные шейдеры длины - не реалистичные в данный момент, либо реализовать эмуляцию шейдерного s/w-шейдера (или, как некоторые поставщики решили просто не соответствовать требованиям). Итак, если вы вызвали это условие на фрагментарный шейдер, скорее всего, весь ваш GL закончил выполнение на процессоре, даже если у вас был простоя GPU, по крайней мере, для этой ничьей.

Ответ 2

Возможно, вопрос должен быть: "Какие функции едят неожиданно большое количество процессорного времени?"

Сохранение матричного стека для проецирования и просмотра - это не то, что GPU может обрабатывать лучше, чем CPU (наоборот...). Другим примером может быть компиляция шейдеров. Зачем это делать на GPU? Существует синтаксический анализатор, компилятор,..., которые являются обычными программами ЦП, такими как компилятор С++.

Потенциально "опасные" вызовы функций - это, например, glReadPixels, поскольку данные могут быть скопированы из памяти хоста (= CPU) в память устройства (= GPU) по ограниченной шине. В эту категорию также входят функции glTexImage_D или glBufferData.

Итак, если вы хотите узнать, сколько времени процессорное время OpenGL вызывает, попробуйте понять его функциональность. И будьте осторожны со всеми функциями, которые копируют данные с хоста на устройство и обратно!

Ответ 3

Как правило, если операция выполняется для чего-то, это произойдет на графическом процессоре. Примером является фактическое преобразование - это делается один раз на вершину. С другой стороны, если это происходит только один раз за большую операцию, оно будет на процессоре - например, создание матрицы преобразования, которая выполняется только один раз для каждого изменения состояния объекта или для каждого кадра.

Это просто общий ответ, и некоторые функции будут происходить наоборот, а также зависят от реализации. Однако, как правило, это не важно для вас, программист. Пока вы позволяете графическому процессору много времени, чтобы сделать это, пока вы не играете в симулятор игры или что-то еще, или имеете прочную модель потоковой передачи, вам не стоит об этом беспокоиться.

@предоставление данных для графического процессора: насколько я знаю (используется только Direct3D), все это делается в шейдере, для чего нужны шейдеры.

Ответ 4

glTranslate, glRotate и glScale изменяют текущую активную матрицу преобразования. Это, конечно, операция ЦП. Матрицы представлений моделей и проекций просто описывают, как GPU должен преобразовывать вершины при выдаче команды рендеринга.

Так, например, по вызову glTranslate все еще не переведено. Перед рендерингом текущая матрица представления проекции и модели умножается (MVP = проекция * modelview), то эта единственная матрица копируется на GPU, а затем GPU выполняет умножение на вершину матрицы * ( "T & L" ) для каждой вершины. Таким образом, преобразование/масштабирование/проектирование вершин выполняется с помощью графического процессора.

Также вам не следует беспокоиться о производительности, если вы не используете эти функции во внутреннем цикле где-то. glTranslate приводит к трем добавлениям. glScale и glRotate немного сложнее.

Мой совет заключается в том, что вы должны немного узнать о линейной алгебре. Это необходимо для работы с 3D-API.

Ответ 5

Существуют программные реализации OpenGL, поэтому возможно, что на GPU не будут работать функции OpenGL. Там также аппаратное обеспечение, которое не поддерживает определенные состояния рендеринга в оборудовании, поэтому, если вы установите определенное состояние, переключитесь на рендеринг программного обеспечения, и снова на GPU ничего не будет (хотя там есть). Поэтому я не думаю, что существует четкое различие между "функциями с ускорением GPU" и "ускоренными функциями без GPU".

Чтобы быть в безопасности, держите вещи как можно проще. Прямые рендеринг-с-вершинами и основными функциями, такими как Z-буферизация, скорее всего, будут аппаратно ускорены, поэтому, если вы можете придерживаться этого с минимальным изменением состояния, вы, скорее всего, будете поддерживать аппаратное ускорение. Это также способ максимизировать производительность аппаратно-ускоренного рендеринга - графические карты, например, оставаться в одном состоянии и просто хрустит кучу вершин.