Tomb Raider : la configuration requise pour PC dévoilée

Le tesselation, ou comment rajouter des polygones par interpolation.

Les économies de bandes passantes du bus sur les données des vertex/primitives sont si intereressantes que ça?? (GROS DOUTES)

Faudrait des chiffres, car sinon autant laisser les 3D designers ajouter les polygones là où ils vont bien.

Edtech a écrit :



La tesselation ne fait pas un bête ajout de polygone au hasard ! C’est directement indiqué dans le modèle comment la tesselation doit s’appliquer. C’est donc exactement comme si le designer l’avait fait lui-même !







Et même si c’était le cas, les algos sont déjà très performants et omniprésents dans le pré-calculé.



https://fr.wikipedia.org/wiki/Surface_de_subdivision

SrBelial a écrit :



Moi j’en vois surtout un autre : réduire le besoin d’utiliser des modèles multirés.

Il n’y a pas que l’ajout de polygones par interpolation, j’ose espérer que leur moteur d’affichage contient également de la simplification des géométries en fonction de la distance dans le frustum (ça y est j’ai placé un terme technique bien pourri)







Le plus grand intérêt serait dans le cas inverse alors? Abaisser le nombre de polygones par interpolation matérielle quand le LOD (Level Of Detail) nécessaire baisse par l’éloignement du modèle 3d.



D’un point de vu technique cela signifierait que les besoins pour le transfère des vertex/primitives restent les mêmes, et sachant que la tesselation ne concerne par les polygones, les textures conserveraient leur qualité (mais seraient samplées nettement moins du au nombre de polygones inférieur).



Par contre interpoler “vers” le bas, signifie qu’il faut plusieurs polygones pour le faire (on va de N polygones vers moins de N), et donc exploiter cette tesselation ne doit pas être “out of the box” et imposer des contraintes aux modèles 3D.



Je me doute bien que ces contraintes, si elles existent doivent être moins lourdes à mettre en œuvre pour le designer 3D… par contre si les contraintes se démultiplient pour chaque gamme de GPUs. c’est perdu car il sera plus intéressant que le designer se coltine un seul modèle pour un LOD qu’un modèle haute résolution pour chaque moteur de tesselation matériel qui existe.



On en retombe bien sur le côté discutable du coût silicium de cette tesselation matérielle.



Y répondre nécessite une analyse sacrément fine, mais la perspective des gains de boulot pour le designer 3D est diablement intéressante… donc ça vaut vraiment le coup d’y regarder de plus près.



Qui s’y colle? " />

Edtech a écrit :



La tesselation ne fait pas un bête ajout de polygone au hasard ! C’est directement indiqué dans le modèle comment la tesselation doit s’appliquer. C’est donc exactement comme si le designer l’avait fait lui-même !.







Ah? Donc ça voudrait dire que le modèle 3D doit être enrichi de “meta” data d’interpolation à la modélisation? Genre des paramètres de courbes mathématiques bien connues (Je regarde wikipédia sur les algos de tesselation “interpolants” et “approximants”). Perso, ça veut dire que le designer 3D va devoir monter en compétences pour être capable de maîtriser ces outils mathématiques qui semblent nettement plus pointues que la 3D polygonale classique.



Oulala… c’est de plus en plus acrobatique!



Est-ce que le boulot des designers 3D à monter en compétences/expérience sur la tesselation économisera les modèles 3D supplémentaires nécessaires au LOD et au dimensionnement du au GPU? On peut parier que chaque GPU à sa façon de faire de la tesselation matérielle, ce qui n’arrangerait rien, car les paramètres de tesselation devraient être démultiplier par le nombre de GPU (vieux, courants ou pas encore sortis?)



Donc re… la perspective des gains de charge de boulot pour les designers 3D seraient tels qu’il faut vraiment faire une étude poussée, très poussée! Car si au final le gain est proche de rien dans la pratique, autant réutiliser ce silicium pour des compute units supplémentaires.

azedrummer a écrit :



…







cf nos posts précédents.



Tu parles de tesselation “montante” et des gains du bande passante sur le bus.



Dans les posts précédents, c’est justement ça qu’il faudrait regarder de bien plus près. Car le profile de charge d’un GPU est compliqué (c’est pas du streaming vidéo quoi).



Donc, dans le plan technique et la tesselation “montante” (vers plus de polygons), la question est:

Est-ce que le gain visuel dans la majorité des cas de figure (pas les benchmarks faits pour que justement ça marche au mieux) est significatif grâce à cette réduction de pression sur le bus mémoire?



Je ne parle pas d’estimation grossière à priori, car comme je l’ai dit, c’est pas du streaming video, mais d’analyse fine et concrète (de terrain).







azedrummer a écrit :



…







Pour ta réponse précédente… le code générique ne suffit plus, sinon on n’aurait pas des news en permanence sur les optimisations des drivers spécifiques pour certains jeux…

Toorist a écrit :



Juste pour faire mon relou, directX est plus un Framework qu’une API " />

A part ca rien a rajouter, moi les modèles j’les utilise je sais pas les faire " /> (chaqu’un son taff merde ! " /> )







Le “framework” (" />) pour opengl c’est là:http://www.khronos.org/

SrBelial a écrit :



Souvent les information nécessaires sont issues d’un modèle très haute résolution (un nombre de polygones indécent) qui est ensuite appliqué à un autre modèle, plus économe en polygones. Ce genre d’informations peut être stocké dans une texture ou une pseudo texture, d’une façon un peu similaire au stockage des éclairages précalculés : au lieu de stocker une couleur dans un pixel d’une texture on peut y stocker un éclairage, un vecteur normal au plan “théorique”, etc …

ne pas oublier que le rendu 3D c’est avant tout de l’illusion " /> avec les bon shaders, les bon calculs, les bonnes textures, on pourrait presque modéliser un cube et donner l’impression lors du rendu qu’il s’agit d’une sphère.







Yope, ça me fait penser au studio où ils ont dev God Of War III (santa monica?). Le pipeline de design graphique avait 3 étages: le premier=les designers 3D de base, le second=les designers 3D avec compétences techniques avancées, et le dernier=les codeurs.







SrBelial a écrit :



en l’occurence, on laisse la main à des artistes, qui même s’ils ne maitrisent pas la théorie, savent l’appliquer pour obtenir le résultat qu’ils veulent. pas besoin de transformer les graphistes en mathématiciens " />







Certes… mais est-ce qu’il y a réellement un gain visuel et/ou en charge de travail?



Pour les gain de charge de travail: designer 3D pour la conception de différents modèles avec un nombre différents de polygones (j’imagine que pour la tesselation “descendante” y a des super outils pour accélérer le boulot) au profit du programmeur du moteur 3D qui a nettement moins de boulot à faire sur le LOD et la gestion de puissance des GPUs (ce que nintendo évite avec un seul hardware pour ses jeux " />).

azedrummer a écrit :



Oui… et non ! ça marche dans les deux sens : les moteurs de jeux s’adaptent aux architectures GPU existantes pour en tirer le meilleur. Les drivers arrivent derrière pour optimiser ce qui l’a déjà été, c’est à dire qu’ils viennent optimiser leurs calculs en fonction de la façon dont les moteurs de jeux utilisent les GPU .Par exemple, l’UE4 et le CE3 n’utilisent pas le même code et par conséquent n’utilisent pas les mêmes optimisations au niveau du GPU, les drivers spécifiques permettent de pousser plus loin cette optimisation en d’adaptant au fonctionnement de chaque moteur.







C’est effectivement un constat. Je le perçois comme une forme d’échec d’opengl et de directx, qui ne sont maintenant que des couches de compatibilité, le “fall back” (ce qui ne veut pas dire que ça marche mal et que c’est pas beau)



Là où ça fait le plus mal, c’est qu’opengl n’expose pas une interface suffisamment bas niveau (plus simple et fine, mais plus bourrine) pour éviter que les drivers soient carrément optimisés (avec tous les problèmes que ça implique). Mais d’un autre côté, quand on voit que les instructions machines des GPUs vont jusqu’au contrôle fin des mémoires cache… instructions qui semblent nettement plus expressives que les instructions machines des CPUs… les compilos glsl peuvent crever pour optimiser une telle finesse (en tout cas c’est l’impression que ça me donne).

Zenedore a écrit :



Si tu as la machine qu’il faut et des jeux directx11, tu peux faire la comparaison toi même, il y a certes une perte de framerate, mais minime par rapport a ce que tu aurais comme chute sans la tesselation mais avec le même nombre de polygones.







Il me semble dans la démo, on voit du 217 fps qui passe à 67 fps voir d’autres…



Mais je viens de regarder quelques vidéos… la killer feature de la tesselation (montante en nombre de polygones) serait l’affinement significatif de l’effet des map d’interpolation de positions des vertex d’un poly selon les normales (si j’ai bien tout compris… ce dont je doute très fortement). En gros, les reliefs dans ces maps seraient beaucoup plus appuyés et nets. Mais dans ces demos, c’est tranché: “scene intended for hardware tesselation”. En gros pas de tesselation, rendu dégradé voir pourri par rapport à ce que voulait le designer 3D…

sylware a écrit :



Il me semble dans la démo, on voit du 217 fps qui passe à 67 fps voir d’autres…



Mais je viens de regarder quelques vidéos… la killer feature de la tesselation (montante en nombre de polygones) serait l’affinement significatif de l’effet des map d’interpolation de positions des vertex d’un poly selon les normales (si j’ai bien tout compris… ce dont je doute très fortement). En gros, les reliefs dans ces maps seraient beaucoup plus appuyés et nets. Mais dans ces demos, c’est tranché: “scene intended for hardware tesselation”. En gros pas de tesselation, rendu dégradé voir pourri par rapport à ce que voulait le designer 3D…



En gros c’est très convainquant en qualité de rendu… tant que les vertex shaders peuvent accéder à fonds les ballons à ces maps d’interpolation, qui par définition seront costoes à cause de leur finesse. D’ailleurs c’est pas ce qu’utilise l’ID5 de Carmack avec ses gigas maps?

SrBelial a écrit :



=> On a donc un graphiste qui a bossé un peu plus sur son modèle, en a fait une version avec un très grand nombre de poly, et grâce à un bake a pu stocker dans une ou plusieurs texture (de façon automatique, sans connaissance particulière nécessaire) les informations nécessaires pour la reconstruction de ces nombreux polys à partir d’un modèle beaucoup moins lourd. C’est cette étape et ces informations qui permettront plus tard d’appliquer les modèles mathématiques évoqués dans les messages précédents.







Je ne suis pas encore versé dans la tesselation hardware (ça arrive… mollo… je viens juste du publier mon assembleur partiel de shader pour GCN d’AMD). Mais ce dont tu parles sont les fameuses map ultra fines d’interpolation des positions des vertex (qui seront lues et appliquées par les vertex shaders). Ce qui me fait un peu peur c’est la pression sur le bus modulo la gestion de la mémoire cache pour que les vertex shaders “tapent” dans cette map à priori costo. Un moteur 3D peut prendre le soin d’abaisser la résolution de cette map pour augmenter l’efficacité de la mémoire cache et par la même occasion alléger la pression sur le bus. Je sais que sur les GCN d’AMD, les vertex shaders ont un contrôle fin sur les niveaux de cache de texture (ceux utilisés par les vertex shaders pour “taper” dans ces maps).

Cela signifie que le modeleur (blender), sait comment le vertex shader va interpoler la position des vertex des polygones pour “baker” cette fameuse map. Or cela est directement dépendant du code de vertex shader qui varie d’un moteur à un autre. C’est donc au programmeur des vertex shaders d’un moteur 3D de fournir les infos ou carrément les plugins pour blender (ouaip, je suis open sourcer et j’assume " />, même si je n’aime pas du tout le c++).

SrBelial a écrit :



…







Bin le truc, si j’ai bien compris, la tesselation hw est faite avant l’étape du vertex shader. Le truc, c’est que le modeleur n’aura aucun pb pour générer la map si c’est de la tesselation à plat, par contre pour de la tesselation, genre “algo qui améliore” les arrondis (pour les ombres portés, etc…), c’est une autre histoire, car le modeleur devrait être capable d’approcher très finement ce que saura faire le GPU pour “baker” les maps qui vont bien. De plus, il faut espérer que le hw place bien ces nouveaux polygones dans tous les cas de figure, ce qui ne serait pas franchement le cas (je présume pour les cas de figures hors du plan).



Comme d’hab: prudence et tests… allez… faut que j’aille faire le désassembleur pour les shaders des GCN d’AMD.

SrBelial a écrit :



Et effectivement de toute façon sur des faces planes il est plus judicieux de supprimer des polys que d’en rajouter " />



bon courage pour ton désassembly ;)







Euuuuh… sauf si tu interpoles la positions des vertex des polygones ajoutés par tesselation avec une map de relief… (c’est ce que montre la majorité des démos sur la tesselation).



Ayé… assembleur/désassembleur dans la boite… partiel, mais le gros de la plomberie est là… je vais maintenant faire le lien entre mon compositeur wl_shell wayland et mon driver de GPU GCN d’AMD.