GL_STATIC_DRAW против GL_DYNAMIC_DRAW против GL_STREAM_DRAW: имеет ли это значение?

В OpenGL функция объекта буфера ( glBufferData, glBufferSubDataи , возможно , некоторые другие) имеет параметр usage, описанный в документации как намек предполагаемого использования, вероятно , имел в вид , чтобы помочь доходности реализации более высокой производительности.

использование

Определяет ожидаемую схему использования хранилища данных. Символьная константа должна быть GL_STREAM_DRAW, GL_STREAM_READ, GL_STREAM_COPY, GL_STATIC_DRAW, GL_STATIC_READ, GL_STATIC_COPY, GL_DYNAMIC_DRAW, GL_DYNAMIC_READ, или GL_DYNAMIC_COPY.
[...]
использование является подсказкой для реализации GL относительно того, как будет осуществляться доступ к хранилищу данных объекта буфера. Это позволяет реализации GL принимать более разумные решения, которые могут существенно повлиять на производительность буферного объекта. Это, однако, не ограничивает фактическое использование хранилища данных.

Вики также расплывчаты:

В конце концов, это только намеки. Это совершенно законный код OpenGL для изменения буфера STATIC после его создания или для того, чтобы никогда не изменять буфер STREAM.
[...]
Это вопросы, на которые можно ответить только с тщательным профилированием. И даже в этом случае ответ будет точным только для конкретной версии драйвера от конкретного поставщика оборудования.

В общем, насколько уместен этот параметр, если вообще? Учитывают ли водители это на самом деле, и если да, то, как вы считаете, насколько это влияет на производительность на практике? У вас есть данные для обмена?

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

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

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

Функционально они одинаковы.

Драйвер может использовать их, чтобы различать, как обращаться с буфером за кулисами. Где, например, static_draw будет скопирован в vram как можно скорее и оставлен там, но stream_read будет всегда иметь копию до даты в оперативной памяти.

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