Я использую OpenGL ES 2.0, но я думаю, что это также относится к не-ES: как узнать, какое "использование" выбрать при создании VBO?
Этот конкретный VBO будет использоваться в 1-4 раза до полного обновления, и я не уверен, что я должен выбрать GL_STREAM_DRAW или GL_DYNAMIC_DRAW.
Ну, в соответствии с OpenGL API вы должны использовать DYNAMIC_DRAW.
STREAM
Вы должны использовать STREAM_DRAW, когда содержимое хранилища данных будет изменено один раз и использовано не более нескольких раз.
СТАТИЧЕСКУЮ
Используйте STATIC_DRAW, когда содержимое хранилища данных будет изменено один раз и использовано много раз.
DYNAMIC
Используйте DYNAMIC_DRAW, когда содержимое хранилища данных будет изменяться повторно и использоваться много раз.
Обязательно обновите VBO с помощью glBufferSubData()
Флаг использования - это подсказка, а не принудительное исполнение. Или другими словами: вещи не сломаются, если вы используете "неправильный" флаг. Поэтому я предлагаю вам попробовать все 3: STATIC_DRAW, STREAM_DRAW и DYNAMIC_DRAW и выбрать тот, который дает вам лучшую производительность - и очень вероятно, что они будут связаны.
Помимо ответов, которые были даны до сих пор, и хотя он не имеет ничего общего с GLES, мне нравится вставлять этот бит из второго выпуска ARB_buffer_storage (вводит вместе с настольным GL 4.4):
2) Новые флаги непосредственно не сопоставляются с параметром для glBufferData, и нельзя выразить в терминах другого. Есть ли это важно?
Большинство приложений получают
usageнеправильно, и они все равно являются намеками. флаги - это жесткие и быстрые правила, которым необходимо следовать. Они служат другой целью. Идея здесь состоит в том, чтобы позволить реализации не должны догадываться о приложении и выполнять меньшее отслеживание, и для приложения больше контроля. Мы определяем BufferData в условия BufferStorage с наиболее либеральными разрешенными флагами (по сути, все идет), но все же передать намек на чтобы он продолжал догадываться приложение.
Проблема с этими флагами всегда заключалась в том, что каждая реализация может иметь разные идеи о том, как оптимизировать разные пути, предлагаемые подсказкой использования, и у каждого приложения, похоже, разные ожидания относительно того, как работает эта оптимизация.
Драйвер Nvidias desktop GL в профиле отладки распечатает некоторые решения, которые он принял для объектов буфера, особенно если они хранятся в ОЗУ клиента или непосредственно на графическом процессоре. Играя с этим, я получил следующее:
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) has been mapped in HOST memory.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) stored in VIDEO memory has been updated.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) has been mapped in HOST memory.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) stored in SYSTEM HEAP memory has been updated.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use SYSTEM HEAP memory as the source for buffer object operations.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use SYSTEM HEAP memory as the source for buffer object operations.
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) has been mapped WRITE_ONLY in SYSTEM HEAP memory (fast).
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) has been mapped WRITE_ONLY in SYSTEM HEAP memory (fast).
Buffer detailed info: Buffer object 5 (bound to GL_PIXEL_UNPACK_BUFFER_ARB, usage hint is GL_STATIC_DRAW) has been mapped WRITE_ONLY in SYSTEM HEAP memory (fast).
То, что я здесь делал, это использование PBO для потоковой передачи обновлений текстур на GPU с одним обновлением на каждый кадр посредством отображения буфера. Естественным выбором здесь будет использование GL_STREAM_DRAW, но я указал GL_STATIC_DRAW. То, что сделал драйвер, это дать мне некоторый буфер, поддерживаемый VRAM, и сделать сопоставление ввода-вывода для первых двух обновлений, которые я сделал. Но потом он изменил свое мнение и использует буфер с поддержкой клиента - давая мне именно тот результат, который я получил бы, если бы попросил GL_STREAM_DRAW в первую очередь. То, что мы видим здесь, является примером для second guessing цитированного выше текста.
Все это очень специфично для реализации. И это также связано с тем, что было создано вышеупомянутое расширение GL, что даст программисту гораздо больший контроль над такими вещами. Однако это расширение, насколько мне известно, недоступно в области OpenGL ES.
Слишком информация о VBO прямо там на сайте разработчика Apple. По пути, если я верю, что вы должны выбрать GL_DYNAMIC_DRAW для обновления рисунка более одного раза.