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, і це спокуса просто ігнорувати цей параметр і приховати його від відкритої абстракції.

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

Деякі помітні ігри, які широко використовуються для порівняльного порівняння між графічними процесорами, не використовують ці підказки правильно, тому постачальники GPU мають стимул швидко використовувати все, навіть якщо вони не відповідають натякам.

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

Водій міг використовувати їх для розрізнення способу обробки буфера поза кадром. Де, наприклад, static_draw буде скопійовано в vram якнайшвидше і залишено там, але stream_read завжди має можливість копіювати дату в оперативній пам'яті.

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