GL_STATIC_DRAW vs GL_DYNAMIC_DRAW vs GL_STREAM_DRAW: czy to ma znaczenie?

W OpenGL funkcje obiektów buforowych ( glBufferData, glBufferSubDatai prawdopodobnie kilka innych) mają parametr usageopisany w dokumentacji jako wskazówka zamierzonego użycia, która prawdopodobnie ma pomóc w poprawie wydajności implementacji.

stosowanie

Określa oczekiwany wzorzec użycia magazynu danych. Stała symboliczny musi być GL_STREAM_DRAW, GL_STREAM_READ, GL_STREAM_COPY, GL_STATIC_DRAW, GL_STATIC_READ, GL_STATIC_COPY, GL_DYNAMIC_DRAW, GL_DYNAMIC_READ, lub GL_DYNAMIC_COPY.
[...]
użycie jest wskazówką do implementacji GL co do sposobu dostępu do magazynu danych obiektu bufora. Umożliwia to implementacji GL podejmowanie bardziej inteligentnych decyzji, które mogą znacząco wpłynąć na wydajność obiektu buforującego. Nie ogranicza to jednak faktycznego wykorzystania magazynu danych.

Wiki jest podobnie niejasne:

W końcu to tylko wskazówki. Jest całkowicie legalnym kodem OpenGL, aby modyfikować bufor STATIC po jego utworzeniu lub nigdy nie modyfikować bufora STREAM.
[...]
Są to pytania, na które można odpowiedzieć tylko poprzez staranne profilowanie. I nawet wtedy odpowiedź będzie dokładna tylko dla tej konkretnej wersji sterownika od tego konkretnego dostawcy sprzętu.

W porządku, jak trafny jest ten parametr, jeśli w ogóle? Czy kierowcy rzeczywiście uwzględniają to, a jeśli tak, to z własnego doświadczenia, w jakim stopniu wpływa to na wydajność w praktyce? Czy masz dane do udostępnienia?

Napisałem cienką warstwę abstrakcji interfejsu API grafiki, która ma być zaimplementowana jako jeden z istniejących interfejsów API i kusi mnie całkowite zignorowanie tego parametru i ukrycie go przed odsłoniętą abstrakcją.

Różni się to w zależności od implementacji, ale sterownik, nad którym pracowałem, używał ich, głównie do decydowania o układzie pamięci. Optymalizacje włączane przez te podpowiedzi są znacznie mniejsze, niż byś chciał, głównie z powodu ograniczenia, że możesz użyć dowolnego podpowiedzi. np. spowodowałoby to, że unieważnienie pamięci podręcznej byłoby znacznie tańsze, gdyby bufory wskazujące tylko na dostęp do odczytu w ogóle nie mogły zostać zapisane, ale ta optymalizacja jest niemożliwa.

Niektóre godne uwagi gry, które są szeroko stosowane do porównywania procesorów GPU, nie używają tych wskazówek poprawnie, więc dostawcy GPU mają motywację do szybkiego korzystania ze wszystkich zastosowań, nawet jeśli nie są zgodne z podpowiedziami.

Funkcjonalnie są takie same.

Sterownik może ich użyć do rozróżnienia sposobu obsługi bufora za kulisami. Gdzie na przykład static_draw zostanie skopiowany do vram jak najszybciej i pozostawiony tam, ale stream_read będzie miał zawsze aktualną kopię w pamięci RAM.

Ta niejasność jest przyczyną, dla której glBufferStorage stał się faktem. W ten sposób określasz, co chcesz zrobić z buforem (czy zaktualizujesz go za pomocą BufferSubData, czy będziesz czytać lub zapisywać mapę, jak spójne jest mapowanie, czy mapowanie może trwać dla różnych zastosowań) i przekroczenie tych granic jest błędem.