Les bénéfices de la virtualisation de textures
Tout ceci est bien joli mais en pratique, qu’est ce que cela change au niveau du jeu ? Plusieurs choses : pour les graphistes cela permet de s’affranchir de toute contrainte concernant les textures. Le graphiste peut utiliser des textures de la taille qu’il veut et venir les placer sur ses modèles sans se soucier des limitations du hardware ou du budget mémoire : au final tout sera combiné dans une seule texture et l’algorithme d’adressage se charge de s’y retrouver.
Au niveau de l’aspect graphique du jeu les MegaTextures offrent de multiples avantages. Les graphistes peuvent se permettre de nombreux détails, en effet contrairement à un moteur classique où le mélange des couches se fait à l’exécution ce qui finit par ralentir le GPU lorsque le nombre de superpositions devient trop élevé, ici les couches sont toutes combinées lors de la compilation de la MegaTexture. Ensuite à l’exécution pour le GPU il s’agit d’une seule texture classique. Les graphistes peuvent donc apporter plus de détails dans leurs textures sans impact sur les performances.
Toujours en terme d’amélioration graphique les graphistes peuvent utiliser des fonctions de mélange plus avancées. Les moteurs classiques utilisent en général une simple interpolation linéaire entre deux textures en utilisant une texture alpha. Afin de masquer la répétition des textures ils utilisent en général plusieurs textures alpha pour faire ce mélange mais cette technique reste limitée.
Avec une unique texture sur laquelle travailler les graphistes ont un contrôle plus précis : au lieu de combiner les textures en utilisant quelques fonctions de mélange prédéfinies ils peuvent gérer ça au texel près en utilisant le mélange qu’ils veulent, inutile de se limiter à une simple interpolation linéaire. Les couches peuvent se mélanger en prenant en compte les informations de la normal map et les graphistes contrôlent tout ça précisément.
Dernier avantage cette fois en terme de performances : la virtualisation de textures permet un meilleur batching. Batching ? En français traitement par lot, un GPU n’est finalement qu’une machine à états : le programmeur spécifie des états qui vont contrôler la façon dont le GPU va rendre les triangles. Typiquement il s’agit d’activer l’application de texture, de spécifier les textures, les shaders, les données géométriques et de lancer le rendu. Pour obtenir les meilleures performances possibles il faut toutefois laisser au GPU la possibilité d’amortir le coût induit par le changement d’états, en clair cela signifie changer les états et ensuite dessiner un nombre non négligeable de triangles partageant ces états. Des changements trop répétés auront un impact particulièrement négatif pour les performances mais par moment il est impossible de faire autrement.
En particulier le changement de textures est une des raisons les plus fréquentes empêchant les gros batchs. Avec id Tech 5 et son unique MegaTexture ce problème est résolu et John Carmack affirme pouvoir effectuer tout le rendu en seulement 3 batchs (un pour le décor, un pour les objets opaques, un pour les objets transparents) ce qui est particulièrement peu. Evidemment tout cela est à relativiser en fonction du coût des algorithmes permettant cette virtualisation de textures, coût qu’il est impossible d’évaluer vu le peu de détails sûrs dont nous disposons, mais si John Carmack et toute l’équipe d’id Software vise un frame rate de 60 i/s même sur les consoles il semble clair que cette technique n’est pas si gourmande que ça.
Excellent article. Dommage que le Cry Engine 2 soit à peine mentionné à la fin, alors que techniquement il n'a clairement pas à rougir face au Unreal Engine 3... sans tout le batage marketing qui est fait à coté de ce dernier.
Pour ma part je suis content de voir J. Carmack revenir dans la course. J'ai toujours admiré son talent (et je suis grand fan de Quake devant l'eternel!) mais j'etais déçu par son travail sur DoomIII.
Concernant la partie numero 7 (suppositions sur l'algo)... C'est vraiment totalement farfelu...
Deja ... Faire un rendu de la scene dans une texture 1000x1000 est vraiment loin d'etre gratuit !! Surtout si la scene en question est chargée en vertices, si y'a beaucoup d'animations en vertex shader, etc... Ca irait sur une petite demo, mais sur un vrai jeu bien chargé, ca coute (relativement) cher ! Rajoutons à ça qu'il faut dans bien des cas utiliser la texture elle meme pour faire ce rendu (dans le cas d'un alpha test)... Les jeux modernes font deja beaucoup de rendus (ZPass, Shadow maps, Rendu final, etc...), inutile d'en rajouter encore un...
Recuperer la texture sur le CPU ensuite, c'est encore pire... Il faut plusieurs trames de decalages pour ne pas bloquer le CPU... Pas tres pratique... Obligé d'utiliser des double ou triple buffers, etc...
Quant à parcourir et traiter le résultat (4Mo pour une render target en 32bits., vu que les RTs 8 ou 16bits ça ne cours plus vraiment les rues) sur le CPU.. Ca ne serait qu'un gros gaspillage de temps CPU (Sans parler de la memoire cache) !
(Et puis recuperer l'information de la page de texture ne suffit pas.. il faut aussi connaitre le niveau de mipmap à utiliser, et certainement d'autres paramètres..)
Y'a quand meme 1000 fois plus rapide et beaucoup beaucoup plus simple pour faire tout ça, et sans embeter le GPU qui a certainement des choses bien plus interessantes à faire !
Concernant la partie numero 7 (suppositions sur l'algo)... C'est vraiment totalement farfelu...
Cette partie est pourtant basé sur un algo existant (cf lien dans l'article) farfelu peut être mais fonctionnel en tout cas
Comme tu le dis toi même plus bas les jeux modernes font déjà un nombre conséquent de passes (ne serait ce que pour les shadow maps tu fais un rendu Z par source lumineuse, 6 pour les sources omni !) je ne vois pas en quoi en faire une de plus ferait subitement s'écrouler les performances.
Dans le pire des cas en ignorant le test alpha tu ramèneras des pages qu is'avèreront inutiles, ça n'est pas vaiment rédhibitoire.
je vois pas pourquoi : ces dernières années c'est de ce genre de techniques utilisant de multiples rendus que sont venus les algorithmes les plus intéressants. Les GPU deviennent de plus en plus puissants autant les exploiter.
ça c'est effectivement déjà un problème plus sèrieux, mais avec les PBO en OpenGL tu dois pouvoir rapatrier ça de façon asynchrone avec d'assez bonnes perfs surtout que le PCI-Express améliore les performances en readback depuis la VRAM (enfin... en théorie même si on voit que dans la pratique c'est pas encore vraiment le cas). Sur les consoles tu n'as aucun problème : le rendu peut se faire directement en mémoire principale.
ça pourrait occupper un des cores de nos chers CPU au lieu de se tourner les pouces
Comme indiqué il ne s'agit que de suppositions basé sur une implémentation fonctionnelle, après il ya sans doute d'autres façons de faire, peut être plus efficaces, 1000 fois plus rapides par contre j'en doute
0) J'ai pas dit que ca ne fonctionnait pas.. loin de là.. Mais c'est utiliser un lance roquette pour ecraser un moustique...
1) Je ne dis pas que les performances vont s'ecrouler.. mais juste qu'un rendu supplementaire, c'est toujours du temps perdu.. Il n'est pas rare qu'un rendu prenne plus d'une ou deux milliseconde... c'est quand meme enorme.. Surtout si on vise le 60fps
1.bis) Le truc des alpha test n'est vraiment pas à negliger..
2) Non, les consoles (du moins la Xbox360 ou la PS3) ne peuvent pas faire de rendu dans la RAM principale.. Il faut rappatrier les render target depuis la VRAM.. Et ca prends un certain temps.
3) Occupper un core... ouai, mais y'a quand meme des trucs nettement plus interessant à lui faire faire nan ? ;-)
4) Ben si.. 1000 fois plus rapide... et largement meme... mais je peux pas trop en dire plus... Disons que globalement.. pourquoi s'embeter alors qu'on peut avoir toutes ces infos quasiment gratos ? ;-)
2) Non, les consoles (du moins la Xbox360 ou la PS3) ne peuvent pas faire de rendu dans la RAM principale.. Il faut rappatrier les render target depuis la VRAM.. Et ca prends un certain temps.
Pour la PS3 il faudrait que je revérifie mais il me semble que ça a été spécifiquement mentionné et globalement toutes les puces NVIDIA en sont capables depuis qu'ils ont introduit le Turbocache même si c'est pas exposé par l'API.
Pour la Xbox 360 c'est carrément sûr et certain, enfin ma tournure n'est peut être pas correcte : sur la Xbox 360 le backbuffer est toujours dans l'EDRAM donc certes le rendu ne se fait pas à proprement parler en RAM, mais il y a une copie systématique dans la mémoire principale lors du swap buffers (et effectue un downsample de l'AA par la même occasion si c'est utilisé) et c'est de la RAM que le RAMDAC tire ses données avant de les balancer à l'écran. En fait il doit même y avoir moyen d'utiliser le MEMXPORT pour écrire les données en mémoire directement en économisant une passe et cette discussion m'a permis de me rappeler d'd'une citation de Carmack qui mentionnait quelque chose de similaire sur l'utilisation du MEMEXPORT, après quelques recherches sur Google j'ai retrouvé ce qu'il disait exactement :
John Carmack
En tout cas ça semble bien confirmer qu'il utilise une passe disctincte pour déterminer les pages nécessaires.
Effectivement, on doit pouvoir utiliser le memexport sur la 360..
Mais c'est pas forcement plus rapide qu'un tracé en EDRAM suivi d'un resolve...
Mais, Carmack ou pas, je ne comprends toujours pas pourquoi s'embeter avec le GPU pour ça alors que toutes les infos sont à portée de main du CPU pour beaucoup moins cher (si on sait s'y prendre) ?!?! O_o
PS : toi aussi t'es du "metier" ?! ;-)
edit : oops "triplon" ;-)
edit : oops "triplon"
Du métier ? euh non
enfin si tu voulais dire dans les jeux vidéos, mais je bosse quand même sur du rendu temps réel.
Pour l'écriture du RSX en RAM principale je me souvenais bien que ça avait été indiqué quelque part :
j'suis à la masse de pas avoir retrouvé ça plus tôt : c'est moi qui avais écrit la news
Donc le RSX peut écrire en RAM principale (à 10.6Go/s mesuré deux fois moins que dans la VRAM) mais effectivement ça ne dit pas qu'il peut faire le rendu en RAM directement, ça pourrait être mesuré lors d'une copie de données de la VRAM à la RAM.
J'te reponds par MP ;-)
Tres bon Article... vraiment interessant, et les commentaires valent également le coup.
Juste une question concernant ces "Megatextures".
Comme je l'ai compris, elles permettent de définir "une partie" des décors, une zone. Mais que se passe t'il lorsque l'on doit afficher une autre zone ? une nouvelle Megatexture est adressée je suppose, mais si l'on souhaite avoir une grande distance d'affichage le moteur ne risque t'il pas de saturer bcp plus rapidement qu'avec un moteur "plus classique" ???
J'imagine un rendu type Oblivion et je me demande comment se type d'algo pourrait supporter cela....
PS : Tres bon site que je re découvre avec grand intérêt avec des articles comme ceux là
doublon...
chacun son tour, désolé.....
de même, vraiment intéressant. on en apprend beaucoup
"Après plusieurs années de silence, id Software sort de son mutisme et se relance dans la bataille des moteurs 3D en venant s’attaquer sérieusement à l’Unreal Engine 3"
cough cough. Non mais serieux carmack en ce moment il est serieusement overrated.. on fait mieux dans notre boite que sa merde de megatextures... on devrait lui vendre notre tech..
C'est quoi ta boite nystep par curiosité ? Quantic Dream ?
"Après plusieurs années de silence, id Software sort de son mutisme et se relance dans la bataille des moteurs 3D en venant s’attaquer sérieusement à l’Unreal Engine 3"cough cough. Non mais serieux carmack en ce moment il est serieusement overrated.. on fait mieux dans notre boite que sa merde de megatextures... on devrait lui vendre notre tech..
c'est vrai que les megatextures c'est pas forcément l'idéal, surtout que niveau qualité des filtrages on y perds pas mal, en tout cas c'est moins propre que des textures classiques + aniso...
On a vraiment l'impression que certains ne lisent que le début et la fin des articles. Le but des megatextures n'est pas de créer la solution ultimes pour les rendus 3D sur PC hyper-puissants. Il s'agit d'une solution élégante permettant une bonne qualité d'image et un Framerate correct. Le tout portable sur différentes architectures et surtout qui soit très simple à utiliser pour les concepteurs de niveaux. Il n'y a pas que la technique qui rentre en ligne de compte dans la conception d'un jeu vidéo....
eu, c'est normal qu'un article de 2007 se retrouve a la une du site en 2009? recyclage?
eu, c'est normal qu'un article de 2007 se retrouve a la une du site en 2009? recyclage?
Il faut croire
Ceci dit c'est un très bon article, qui est loin d'être périmé : il faudrait juste une petite mise à jour pour les évolutions depuis 2 ans !
Erreur technique, désolé
ZeJeff,
Pourquoi avoir tant de doutes quand à ses travaux ? Aussi, bien qu'intéressant, je m'étonne de ton raisonnement. Faut-il rappeler que John Carmack a réalisé le premier FPS (Quake) à présenter un environnement totalement en 3D dans l'histoire du jeu vidéo et dont des dizaines de sociétés ont acheté leur moteur ? (dont Valve Software pour réaliser Half-Life par la suite). Il est l'un des plus célèbre développeur indépendant capable de réaliser des moteurs graphiques exploitant au maximum les évolutions du atériel, en particulier des cartes graphiques pour PC. Il a rejoint le panthéon des développeurs de l'Académie des Arts et des Sciences Interactifs. L'année dernière, il fût de nouveau récompensé par l'GDC Lifetime Award. Le moteur de Quake 3 a été également le plus abouti en 1999-2000 (sachant que les cartes vidéos de l'époque n'étaient pas aussi avancées qu'aujourd'hui).
C'est également lui qui a inventé plusieurs algorithmes 3D les plus rapides et les plus avancés, dont celui du "Carmack's Reverse" ou "Robust Stencil Shadow Volumes" pour Doom 3 (calcul des ombres en temps réel dans une scène graphique en 3D utilisé pour la toute première fois dans le monde du jeu vidéo en 2003-2004). Sans compter que pratiquement tous les jeux d'Id Software tournent également sous GNU/Linux et MAC, ce qui est très rare chez les autres développeurs de jeux vidéo ! Par ailleurs, Doom 3 a été le premier jeu à réellement exploiter le potentiel du circuit graphique de la carte vidéo GeForce 3 ! Je citerais le bump mapping, le normal mapping, le specular highlighting, unified lighting et shadowing, shadow volume, megaTexture. Ses travaux sont reconnus depuis fort longtemps comme étant très souvent les plus avancés.
Je pense qu'il est devenu si banale de nos jours avec tous les nouveaux jeux sur PS3, PC et XBOX360 qui ont découler bien souvent de ses travaux, que beaucoup de gens semblent l'avoir oublié. De ce fait, je crois très sincèrement qu'il n'y a aucun souci à se faire, de remettre en cause ses travaux où d'avoir des doutes quand a leurs utilités futures. Et puis, il est suffisamment bien placé pour savoir ce qui sera utile ou non pour les jeux vidéo et pour les cartes vidéos de demain. Il est bon d'avoir un esprit critique ZeJeff, mais il faudrait éviter de ternir cette qualité par un esprit d'immobilisme et de se faire des noeux au cerveau.