Дерево устранения избыточности состояния OpenGL, приоритеты состояния рендеринга

Относительные затраты на такие операции, конечно, будут зависеть от модели использования и вашего общего сценария. Но вы можете найти слайды презентации Nvidia "Beoynd Porting" в качестве полезного руководства. . Позвольте мне особенно воспроизвести здесь слайд 48:

Относительная стоимость изменения состояния

• В снижении стоимости ...
• Цель рендеринга ~ 60 К / с
• Программа ~ 300К / с
• ROP
• Привязка текстур ~ 1,5 М / с
• Формат вершины
• Наручники UBO
• Единообразные обновления ~ 10M / s

Это не соответствует напрямую всем пунктам вашего списка. Например. glEnable/glDisable может повлиять на что угодно. Кроме того, привязки буфера GL не являются чем-то, что непосредственно видит графический процессор. Привязки буфера - это в основном состояние на стороне клиента, конечно, в зависимости от цели. Изменение состояния смешивания будет изменением состояния ROP и так далее.

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

Со всеми этими оговорками:

• Переключение целевого объекта рендеринга (FBO) обычно обходится довольно дорого. Однако сильно зависит от платформы и архитектуры. Например, если у вас есть какая-то форма архитектуры на основе плиток, ожидающий рендеринг, который в идеале должен быть отложен до конца кадра, может быть завершен и списан. Или в более «классических» архитектурах могут быть сжатые цветовые буферы или буферы, используемые для раннего тестирования глубины, которые необходимо учитывать при переключении целей рендеринга.

• Обновление данных текстуры или буфера невозможно оценить в общих чертах. Очевидно, это сильно зависит от того, сколько данных обновляется. Вопреки некоторым заявлениям в Интернете, вызовы типа glBufferSubData() и glTexSubImage2D() не обычно вызывают синхронизацию. Но они включают копии данных.

• Связывающие программы не должны быть очень дорогими, но, как правило, они более тяжелы, чем изменения состояния, указанные ниже.

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

• Единые обновления. Предположительно это очень быстро на некоторых платформах. Но на самом деле для других это умеренно дорого. Так что здесь много вариаций.

• Настройка состояния вершины (включая привязку VBO и VAO) обычно выполняется быстро. Это должно быть так, потому что это так часто делается большинством приложений, что очень быстро может стать узким местом. Но есть те же соображения, что и для текстур, где буферная память может быть скопирована / отображена, если она не использовалась в последнее время.

• Обновления общего состояния, такие как состояния наложения, состояние трафарета или маски записи, обычно выполняются очень быстро. Но могут быть очень существенные исключения.

Просто типичный пример того, почему характеристики могут быть такими разными в разных архитектурах: если вы измените состояние смешивания, это может привести к отправке пары командных слов в одной архитектуре с минимальными накладными расходами. На других архитектурах смешивание выполняется как часть фрагментного шейдера. Поэтому, если вы измените состояние наложения, программа шейдера должна быть изменена, чтобы исправить код для нового вычисления смешивания.