A ma connaissance, plus personne n'utilise les display lists dans le monde du jeu vidéo: tout passe par des VBO. Et, oui, le contenu de ces VBO est géré par le développeur.
Alors soit on ne parle pas de la même chose, soit tu le fais exprès. Que l'on soit en vertex array, en display list, en VBO ou en PBO de toute façon le contenu est géré à la main. Les VBO sont plutôt une fosi de plus une prise de distance vis à vis du GCU par rapport aux vertex array qui devaient être renvoyés au serveur en permanence.
Le GROS avantage des VBO est que le developpeur, une fois qu'il a optimisé ses vertex n'a plus qu'à donner au pilote des indications d'usage du VBO et qu'ensuite la carte graphique se charge de placer et de déplacer la zone mémoire pratiquement sans intervention du dev.
C'est exactement ce à quoi je pensais end isant qu'on a pas vraiment des GC car la problématique est différente, mais qu'on a quand même des systèmes qui y ressemblent furieusement.
Je ne comprends pas pourquoi tu parles de gérer les shaders vertex par vertex, où de réécrire les "fonctions de z-buffer". Quel est le rapport avec la gestion mémoire?
Le rapport est que toutes ces opérations provoquent un bon nombre de transformations en mémoire. Trier les vertexs pour éviter de transformer des segments inutiles, mapper les vertexs dans les buffers pour préparer à l'affichage, rappler les textures et les PBO pour y appliquer les pixels shaders qui vont bien etc. Une trè grosse partie de tout celà est transparente, soit géré par le pilote OpenGL lui même, soit directement en hard par la carte. Sans parler des couches d'anti-aliasing, de décompression de texture et autres culling.
Même si OpenGL offre des méthodes pour toucher à tout celà, une grosse partie du traitement reste souvent en automatique.
Les uniforms buffers permettent surtout d'allouer un bloc de mémoire GPU et de choisir ce que l'on va y stocker, afin d'optimiser le transferts des uniforms entre le CPU et le GPU. Cela en lieu et place d'une allocation transparente gérée par l'API. Donc oui, on est dans plein dans le vif du sujet: passer d'une gestion automatisée à une gestion manuelle.
A l'époque du T&L on était en gestion automatisée. Quand on est passé au shaders (et donc au moment ou il fallait renvoyer les info transformée au serveur) totu se faisait à la mano. Maintenant avec les Uniform Buffer on peut allouer des blocs qui seront raffraichi automatiquement sur des évènements. Il est normal que s'ait été automatique au moment du T&L car on ne transformait pas les polygones/pixels. On avait pas les outils pour. Depuis qu'on les a les cartes graphiques font à chaque géénration un peu plus de choses en automatique.
Si un GC n'est pas capable de garantir que pour une scène de telle complexité son temps d'exécution sera inférieur à une valeur donnée, cela revient à autoriser la dégradation du framerate par un facteur inconnu...
Mais cite moi un outil capable de garantir ce temps d'éxecution ! Un outil capable de dire qu'il aura la priorité kernel, que le swap ne se déclenchera pas, que l'anti virus ne fera pas des siennes, que la température ne forcera pas le CPU/GPU à ralentir, que le pilote ne prendra pas de libertés avec le rendu demandé (NVidia, on t'aime), que l'utilisateur ne forcera pas des options graphiques à la con (ATI, on t'aime aussi), qu'il n'y aura pas de micro corruption des buffer suite à un refresh à la barbare et j'en passe.
En plus un GC moyennant un surcout en mémoire est beaucoup plus à même de garantir un temps d'éxecution qu'une gestion native. Surtout sur des traitements de type DSP.
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 3.
Alors soit on ne parle pas de la même chose, soit tu le fais exprès. Que l'on soit en vertex array, en display list, en VBO ou en PBO de toute façon le contenu est géré à la main. Les VBO sont plutôt une fosi de plus une prise de distance vis à vis du GCU par rapport aux vertex array qui devaient être renvoyés au serveur en permanence.
Le GROS avantage des VBO est que le developpeur, une fois qu'il a optimisé ses vertex n'a plus qu'à donner au pilote des indications d'usage du VBO et qu'ensuite la carte graphique se charge de placer et de déplacer la zone mémoire pratiquement sans intervention du dev.
C'est exactement ce à quoi je pensais end isant qu'on a pas vraiment des GC car la problématique est différente, mais qu'on a quand même des systèmes qui y ressemblent furieusement.
Je ne comprends pas pourquoi tu parles de gérer les shaders vertex par vertex, où de réécrire les "fonctions de z-buffer". Quel est le rapport avec la gestion mémoire?
Le rapport est que toutes ces opérations provoquent un bon nombre de transformations en mémoire. Trier les vertexs pour éviter de transformer des segments inutiles, mapper les vertexs dans les buffers pour préparer à l'affichage, rappler les textures et les PBO pour y appliquer les pixels shaders qui vont bien etc. Une trè grosse partie de tout celà est transparente, soit géré par le pilote OpenGL lui même, soit directement en hard par la carte. Sans parler des couches d'anti-aliasing, de décompression de texture et autres culling.
Même si OpenGL offre des méthodes pour toucher à tout celà, une grosse partie du traitement reste souvent en automatique.
Les uniforms buffers permettent surtout d'allouer un bloc de mémoire GPU et de choisir ce que l'on va y stocker, afin d'optimiser le transferts des uniforms entre le CPU et le GPU. Cela en lieu et place d'une allocation transparente gérée par l'API. Donc oui, on est dans plein dans le vif du sujet: passer d'une gestion automatisée à une gestion manuelle.
A l'époque du T&L on était en gestion automatisée. Quand on est passé au shaders (et donc au moment ou il fallait renvoyer les info transformée au serveur) totu se faisait à la mano. Maintenant avec les Uniform Buffer on peut allouer des blocs qui seront raffraichi automatiquement sur des évènements. Il est normal que s'ait été automatique au moment du T&L car on ne transformait pas les polygones/pixels. On avait pas les outils pour. Depuis qu'on les a les cartes graphiques font à chaque géénration un peu plus de choses en automatique.
Si un GC n'est pas capable de garantir que pour une scène de telle complexité son temps d'exécution sera inférieur à une valeur donnée, cela revient à autoriser la dégradation du framerate par un facteur inconnu...
Mais cite moi un outil capable de garantir ce temps d'éxecution ! Un outil capable de dire qu'il aura la priorité kernel, que le swap ne se déclenchera pas, que l'anti virus ne fera pas des siennes, que la température ne forcera pas le CPU/GPU à ralentir, que le pilote ne prendra pas de libertés avec le rendu demandé (NVidia, on t'aime), que l'utilisateur ne forcera pas des options graphiques à la con (ATI, on t'aime aussi), qu'il n'y aura pas de micro corruption des buffer suite à un refresh à la barbare et j'en passe.
En plus un GC moyennant un surcout en mémoire est beaucoup plus à même de garantir un temps d'éxecution qu'une gestion native. Surtout sur des traitements de type DSP.