GL_STATIC_DRAW vs GL_DYNAMIC_DRAW vs GL_STREAM_DRAW: est-ce important?

Dans OpenGL les fonctions d'objet tampon ( glBufferData, glBufferSubDataet probablement quelques autres) ont un paramètre usage, décrit par la documentation comme une indication de l'utilisation prévue, probablement destiné à aider le rendement de la mise en œuvre de meilleures performances.

usage

Spécifie le modèle d'utilisation attendu du magasin de données. Doit être la constante symbolique GL_STREAM_DRAW, GL_STREAM_READ, GL_STREAM_COPY, GL_STATIC_DRAW, GL_STATIC_READ, GL_STATIC_COPY, GL_DYNAMIC_DRAW, GL_DYNAMIC_READou GL_DYNAMIC_COPY.
[...] l'
utilisation est une indication de l'implémentation GL quant à la façon dont le magasin de données d'un objet tampon sera accessible. Cela permet à l'implémentation GL de prendre des décisions plus intelligentes qui peuvent avoir un impact significatif sur les performances des objets tampons. Il ne limite cependant pas l'utilisation réelle du magasin de données.

Le wiki est tout aussi vague:

Ce ne sont que des indices, après tout. C'est un code OpenGL parfaitement légal de modifier un buffer STATIC après sa création, ou de ne jamais modifier un buffer STREAM.
[...]
Ce sont des questions auxquelles on ne peut répondre qu'avec un profilage soigneux. Et même alors, la réponse ne sera exacte que pour cette version de pilote particulière de ce fournisseur de matériel particulier.

In fine, quelle est la pertinence de ce paramètre, le cas échéant? Les conducteurs en tiennent-ils compte et, dans l'affirmative, dans quelle mesure cela affecte-t-il les performances dans la pratique? Avez-vous des données à partager?

J'ai écrit une couche d'abstraction d'API graphique fine destinée à être implémentée comme l'une des API existantes, et il est tentant d'ignorer complètement ce paramètre et de le cacher de l'abstraction exposée.

Cela variera selon les implémentations, mais le pilote sur lequel j'ai travaillé les a utilisées, principalement pour décider de la disposition de la mémoire. Les optimisations activées par ces astuces sont beaucoup plus petites que vous ne le souhaiteriez, principalement en raison de la restriction que vous pouvez faire n'importe quelle utilisation des astuces que vous donnez. Par exemple, cela rendrait l'invalidation du cache beaucoup moins chère si les tampons suggérés pour l'accès en lecture seulement ne pouvaient pas être écrits du tout, mais cette optimisation est impossible.

Certains jeux notables qui sont largement utilisés pour les comparaisons de référence entre les GPU n'utilisent pas ces conseils correctement, donc les fournisseurs de GPU sont incités à faire toutes les utilisations rapidement même s'ils ne correspondent pas aux conseils.

Fonctionnellement, ce sont les mêmes.

Le pilote pourrait les utiliser pour différencier la façon de gérer le tampon en arrière-plan. Par exemple, où static_draw serait copié sur vram dès que possible et laissé là mais stream_read aurait une copie op to date en RAM à tout moment.

Ce flou est la raison pour laquelle glBufferStorage est devenu une chose. De cette façon, vous spécifiez ce que vous voulez pouvoir faire avec le tampon (si vous le mettez à jour via BufferSubData, si vous lisez ou écrivez dans une carte, la cohérence du mappage, si le mappage peut persister entre les utilisations) et sortir de ces limites est une erreur.