GL_STATIC_DRAW vs GL_DYNAMIC_DRAW vs GL_STREAM_DRAW: Ist das wichtig?

In OpenGL die Pufferobjektfunktionen ( glBufferData, glBufferSubDataund wahrscheinlich ein paar andere) haben einen Parameterusage , durch die Dokumentation als Hinweis auf die beabsichtigte Verwendung beschrieben, die die Umsetzung Ausbeute bessere Leistung zu helfen bedeutete.

Verwendung

Gibt das erwartete Verwendungsmuster des Datenspeichers an. Die symbolische Konstante sein muss GL_STREAM_DRAW, GL_STREAM_READ, GL_STREAM_COPY, GL_STATIC_DRAW, GL_STATIC_READ, GL_STATIC_COPY, GL_DYNAMIC_DRAW, GL_DYNAMIC_READ, oder GL_DYNAMIC_COPY.
[...] Die
Verwendung ist ein Hinweis auf die GL-Implementierung, wie auf den Datenspeicher eines Pufferobjekts zugegriffen wird. Auf diese Weise kann die GL-Implementierung intelligentere Entscheidungen treffen, die die Leistung von Pufferobjekten erheblich beeinträchtigen können. Die tatsächliche Nutzung des Datenspeichers wird dadurch jedoch nicht eingeschränkt.

Das Wiki ist ähnlich vage:

Dies sind schließlich nur Hinweise. Es ist völlig legal, OpenGL-Code zu verwenden, um einen STATIC-Puffer nach seiner Erstellung zu ändern oder niemals einen STREAM-Puffer zu ändern.
[...]
Dies sind Fragen, die nur mit sorgfältiger Profilerstellung beantwortet werden können. Und selbst dann ist die Antwort nur für diese bestimmte Treiberversion von diesem bestimmten Hardwareanbieter korrekt.

Wie relevant ist dieser Parameter, wenn überhaupt? Berücksichtigen die Fahrer dies tatsächlich und wenn ja, wie stark wirkt es sich Ihrer Erfahrung nach auf die Leistung in der Praxis aus? Haben Sie Daten zum Teilen?

Ich habe eine dünne Grafik-API-Abstraktionsschicht geschrieben, die als eine der vorhandenen APIs implementiert werden soll, und es ist verlockend, diesen Parameter einfach ganz zu ignorieren und ihn vor der exponierten Abstraktion zu verbergen.

Dies variiert zwischen den Implementierungen, aber der Treiber, an dem ich gearbeitet habe, hat diese hauptsächlich verwendet, um das Speicherlayout zu bestimmen. Die durch diese Hinweise aktivierten Optimierungen sind viel kleiner als Sie möchten, hauptsächlich aufgrund der Einschränkung, die Sie können jede Anwendung tun , was auch immer Hinweise , die Ihnen geben. Zum Beispiel würde es die Cache-Ungültigmachung viel billiger machen, wenn Puffer, die nur für den Lesezugriff angedeutet sind, überhaupt nicht geschrieben werden könnten, aber diese Optimierung ist unmöglich.

Einige bemerkenswerte Spiele, die häufig für Benchmark-Vergleiche zwischen GPUs verwendet werden, verwenden diese Hinweise nicht korrekt. Daher haben GPU-Anbieter einen Anreiz, alle Anwendungen schnell durchzuführen, auch wenn sie nicht mit den Hinweisen übereinstimmen.

Funktionell sind sie gleich.

Der Fahrer könnte sie verwenden, um zu unterscheiden, wie mit dem Puffer hinter den Kulissen umgegangen werden soll. Wobei beispielsweise static_draw so schnell wie möglich nach vram kopiert und dort belassen würde, stream_read jedoch jederzeit über eine aktuelle Kopie im RAM verfügt.

Diese Unbestimmtheit ist der Grund, warum glBufferStorage zu einer Sache wurde. Auf diese Weise geben Sie an, was Sie mit dem Puffer tun möchten (ob Sie ihn über BufferSubData aktualisieren, ob Sie eine Karte lesen oder schreiben, wie kohärent die Zuordnung ist, ob die Zuordnung über Verwendungszwecke hinweg bestehen kann). und über diese Grenzen hinauszugehen ist ein Fehler.