La virtualisation de textures
Le problème de cette première version de la technologie est qu’elle ne pouvait s’appliquer qu’aux terrains, ou plus précisément à toute géométrie pouvant être assimilée à un plan déformé. Avec id Tech 5 John Carmack a poussé plus loin le concept afin de pouvoir l’utiliser sur des géométries arbitraires. Mais concrètement comment ça marche ? Le concept est finalement proche de celui utilisé par la gestion de la RAM sur les CPU : une application et ses données ne sont pas chargées en RAM comme un seul bloc, en réalité tout est décomposé en pages de quelques kilo octets et seules les données nécessaires à un instant T sont présentes en RAM, les autres restent sur le disque dur.
Pour gérer tout cela un mécanisme de traduction d’adresses se charge de donner l’illusion à l’application qu’elle dispose d’une zone mémoire contiguë dans laquelle toutes les données sont disponibles alors qu’en pratique les pages sont éparpillées partout en mémoire et sur le disque : c’est le concept de mémoire virtuelle, le CPU ne manipule que des adresses virtuelles qui sont ensuite traduites en adresse physique par une unité dédiée (la MMU : Memory Management Unit). Si la page est présente en mémoire l’adresse virtuelle est remplacée par la véritable adresse dans la RAM, sinon la page est chargée en mémoire depuis le disque dur (on parle de défaut de page). Cette technique permet plusieurs choses : tout d’abord un mécanisme de protection (la MMU qui se charge de la traduction d’adresse ne laisse pas à un processus l’accès à une page mémoire qui ne lui appartient pas) et surtout un mécanisme permettant d’utiliser des applications nécessitant plus de mémoire qu’il n’y en a physiquement dans l’ordinateur.
Ainsi sur un système 32 bits, chaque processus dispose de son propre espace d’adressage de 4 Go (en général sous Windows 2 Go sont réservés au noyau, le processus ne peut donc utiliser que 2 Go) et tant que sa consommation mémoire reste dans la limite de cette taille il n’y a pas de problème, même si l’ordinateur dispose d’une quantité de mémoire physique nettement plus faible. Il convient de noter qu’aujourd’hui la quantité de mémoire physique flirte dangereusement avec les limites de l’adressage 32 bits accélérant le besoin d’une transition vers un adressage 64 bits.
Revenons à id Tech 5. Le problème consistant à placer une texture de plusieurs Go dans une mémoire de quelques centaines de Mo au mieux ne vous rappelle-t-il pas celui que nous venons de décrire ? Et bien la solution est exactement la même : dans les faits cette immense texture n’a jamais besoin d’être présente en mémoire dans son intégralité, par conséquent les textures comme nous l’avons vues sont découpées en tiles et ceux-ci sont chargés en VRAM uniquement selon les besoins, la RAM principale agit comme une zone de stockage intermédiaire, une sorte de mémoire cache venant tirer parti des principes de localité spatiale et temporelle. En effet lorsque le moteur demande une portion de la MegaTexture pour un frame donné il y a de fortes chances que pour le frame suivant il ait besoin d’une portion proche. Ainsi lorsqu’une partie est ramenée depuis le disque dur puis décompressée, autant en prendre un peu plus que nécessaire afin d’accélérer les accès suivants.
Dans la théorie c’est très beau, dans la pratique toute la difficulté consiste à déterminer quelles pages sont nécessaires pour un frame donné, et ensuite à programmer un shader permettant de texturer la géométrie avec toutes ses petites pages éparpillées en VRAM. Un des problèmes se posant concerne notamment le filtrage : que se passe-t-il par exemple aux bords des pages ? Si les pages sont chargées sous la forme d’un atlas de textures (plusieurs petites textures compactées dans une grosse texture pour plus d’efficacité) l’unité de texture du GPU utilisera des texels d’une texture qui n’a rien à voir lors du filtrage, ce n’est donc pas utilisable tel quel.
Soyons clairs, John Carmack n’a pas (encore ?) détaillé le fonctionnement de son algorithme. Il faut dire que sa volonté d’ouverture du temps de Doom III a peut être coûté cher à id Software. En effet plusieurs développeurs se sont inspirés de ses travaux pour reprendre certains concepts tout en se dépêchant de sortir leurs jeux en premier, mais plus grave une société comme Creative Labs a menacé id Software de procès sur la base d’un ancien brevet. Malgré cette absence de détails on peut quand même faire quelques suppositions, prévenons toutefois les âmes sensibles : la partie qui suit est assez technique, si vous ne souhaitez pas entrer dans les détails de l’algorithme mais juste avoir une idée des possibilités offertes n’hésitez donc pas à passer directement à la section suivante.
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.