Bui Tuong Phong

Bui Tuong Phong, nom de famille Bui Tuong et prénom Phong, était un étudiant à l’Université de l’Utah à Salt Lake City. Ce n’est d’ailleurs pas une coincidence si c’était la même université que celle d’Henri Gouraud, l’université ayant abrité de nombreux pionniers du graphisme sur ordinateur.

Henri Gouraud avait popularisé le lissage qui porte son nom et qui interpolait une couleur calculée à chaque sommet d’un triangle. Cela fonctionnait suffisamment bien pour certaines scènes et certains modèles d’éclairage.. Mais une chose qui était évidente c’est que c’était inadapté pour un modèle d’éclairage plus avancé, en particulier un modèle qui peut reproduire les reflets spéculaires. En effet le modèle utilisé pour illustrer le lissage de Gouraud utilisait un modèle Lambertien (on y reviendra) qui a la particularité de varier relativement peu avec la lumière ou le changemenet de point de vue de l’observateur. Le reflet spéculaire est à l’inverse extrêmement changeant et dans certains cas quasi-ponctuel (réduit à un point).

Ci dessus est un rendu d’un modèle d’éclairage qui tient compte des reflets spéculaires d’une surface avec une source de lumière ponctuelle. Comme le reflet de cette lumière est relativement petit, le calcul de l’éclairage par sommet ne capture l’effet de surbrillance qu’occasionnellement ce qui cause un clignotement apparent. Ce clignotement n’est pas désirable dans ce cas. Il n’est pas possible de capturer cet effet de surbrillance - appelé highlight en Anglais - en se contentant d’un calcul d’éclairage par sommet, ou alors il faut augmenter considérablement la densité du maillage 3D au point où ça rendrait caduque tout gain gagné par une interpolation.

Phong Shading - Lissage de Phong

L’idée de Phong était donc de prendre une approche hybride. Plutôt que d’interpoler la valeur finale de l’éclairage sur le triangle, on peut interpoler la normale à la surface calculée initialement à chaque sommet. La normale, aussi appelé vecteur normal, est un raccourci pour représenter l’orientation d’une surface relativement plane. C’est ce vecteur normal qui est le plus souvent présent dans les calculs d’éclairage. En interpolant le vecteur normal cela donne la possibilité de faire un calcul d’éclairage par pixel plutôt que par sommet. Ce calcul d’éclairage par pixel va capturer les plus petites variations dans les reflets spéculaires.

Cela repose sur le fait que l’interpolation de la normale même si elle n’est pas parfaite est une approximation proche de l’orientation de la courbe sous-jacente. En supposant que l’on cherche à représenter un objet courbe comme la sphère de la vidéo ci-dessus.

En pseudo code ça pourrait donner cela :

pour chaque triangle ABC
  calculer la normale Na du triangle au point A
  calculer la normale Nb du triangle au point B
  calculer la normale Nc du triangle au point C
  pour chaque pixel(X,Y) appartenant au triangle ABC
    Calculer les coordonnées barycentriques de (X,Y) au point A, au point B, au point C : Wa, Wb, Wc
    normale au pixel (X,Y) = Wa * Na + Wb * Nb + Wc * Nc
	couleur du pixel (X,Y) = éclairage (normale au pixel (X,Y) )

Voici une illustration du phong shading dans une scène simple :

Le lissage de Phong améliore la capture de la surbrillance spéculaire comme prévu, mais on peut aussi remarquer que le terme diffus de l’éclairage est lui aussi plus précis. C’est particulièrement facile à remarquer aux frontière de la partie éclairée et de la partie dans l’ombre de la sphère.

Le lissage de Phong même s’il a été inventé peu de temps après celui de Gouraud, a mis beaucoup de temps a être adapté au jeu vidéo. Si l’interpolation de la couleur est relativement simple à mettre en place dans les puces graphiques, celui de la normale et surtout le calcul précis de l’éclairage après interpolation au niveau de chaque pixel n’était pas trivial pour les accélérateurs simples des premières années.

Aux alentours de la sortie de la première carte accélératrice 3DFX, la Voodoo 1, les jeux ont commencé à tirer partie de l’interpolation de la couleur par pixel. Puis elles ont continué à se complexifier en ajoutant plusieurs unités de textures, plusieurs interpolateurs matériel de couleur (par exemple un interpolateur pour la couleur diffuse et un autre pour la couleur spéculaire), des profondeurs de couleurs plus étendues, etc.. Mais il manquait toujours quelque chose pour rendre le calcul d’éclairage par pixel vraiment possible. Ce n’était pas forcément juste une question de performance mais de capacité.

Ce n’est qu’à l’arrivée de puces relativement programmables, basées sur les shaders, que l’adoption fréquente d’un éclairage par pixel dans les jeux a pu se faire.

Doom 3 et son éclairage par pixel - reflets spéculaires

X2 the threat et son éclairage par pixel - reflets spéculaires

Depuis cette époque quasiment tous les jeux en 3D l’ont adopté (en ignorant certaines plateformes mobiles comme les téléphones portables qui ont marqué une régression temporaire, et en ignorant certains jeux qui persévèrent dans un style un peu plus rétro et low tech). On parle de lissage de Phong ou d’éclairage par pixel, Per Pixel Lighting en Anglais, au choix et parfois indistinctement. En théorie le lissage de Phong est le précurseur, inventé dans les années 70, mais l’éclairage par pixel est définitivement une continuation de la même idée. Dans un proche-moyen futur, les modèles d’éclairage seront de plus en plus complexes, aucune comparaison par exemple entre l’éclairage et le réalisme de Doom 3 et de ceux sortis plus récemment en 2015. Mais pendant que ces modèles se complexifient, les normales continueront d’être interpolées sur les triangles et les calculs d’éclairage continueront à se faire par pixel en prenant la normale comme principal argument. Et donc d’une certaine façon le lissage de Phong perdure.

Modèle Spéculaire de Phong

Il y a parfois une confusion dans le monde du graphisme sur ordinateur entre deux concepts distincts introduit par Bui Tuong Phong lors de sa thèse. Celui dont on a parlé ici est une méthode d’interpolation de normales sur un triangle. L’autre concept qui porte le nom de Phong est un algorithme d’éclairage qui modélise les reflets spéculaires de manière explicite par une fonction simple et empirique. C’est le modèle spéculaire de Phong ou Blinn-Phong (il existe des variantes) qui est aussi beaucoup utilisé dans les jeux vidéo. On en parlera plus tard. Ces deux concepts sont indépendants au point où l’on peut faire du lissage de Phong en utilisant un tout autre modèle d’éclairage que celui du spéculaire de Phong, et vice versa on peut utiliser un modèle spéculaire de Phong avec par exemple un lissage de Gouraud (le calcul spéculaire a donc lieu par sommet à la place d’être fait par pixel).

Henri Gouraud

Henri Gouraud était un étudiant à l’Université de l’Utah à Salt Lake City quand lui est venu l’idée du lissage qui porte son nom. Avant cela les triangles étaient le plus souvent rempli par une couleur constante, le lissage plat décrit dans la première partie.

L’idée était de calculer l’éclairage et la couleur aux trois sommets d’un triangle (les sommets sont appelés vertex, pluriel vertices, en Anglais). Puis de déterminer la couleur à l’intérieur du triangle par une simple interpolation linéaire. Pour les objets courbes rendus par des polygones, cette méthode permettait donc de donner l’illusion d’une courbure sur le triangle.

L’une des premières images rendues par cette méthode était l’image d’un visage. Le visage était une modélisation 3D de celui de la femme d’Henri Gouraud, Sylvie.

Sylvie Gourand et premier modèle 3D avec lissage de Gouraud

Un visage est un exemple de surface courbe qui ne peut pas être approché par un faible nombre de polygones au rendu plat. La gradation des couleurs à l’intérieur des polygones permet donc de donner l’impression d’une plus grande continuité des surfaces.

Gouraud Shading - Lissage de Gouraud

En pseudo code ça pourrait donner cela :

pour chaque triangle ABC
  calculer la couleur Ca du triangle au point A
  calculer la couleur Cb du triangle au point B
  calculer la couleur Cc du triangle au point C
  pour chaque pixel(X,Y) appartenant au triangle ABC
    Calculer les coordonnées barycentriques de (X,Y) au point A, au point B, au point C : Wa, Wb, Wc
    couleur du pixel (X,Y) = Wa * Ca + Wb * Cb + Wc * Cc

Les W varient entre 0 et 1, ils valent exactement 1 quand le point à évaluer est au sommet correspondant (Wa = 1 au point A), et 0 quand on se trouve au sommet opposé (Wa = 0 au point B et au point C).

Les coordonnées barycentriques sont une manière de décrire l’opération qui est faite mais il y en a d’autres, plus ou moins adaptées au hardware. À chaque point du triangle la couleur est donc une moyenne pondérée de chaque couleur aux sommets.

Voici une illustration du gouraud shading dans une scène simple :

Un accélérateur 3D moderne, un GPU, va gérer le lissage de Gouraud par défaut. C’est quelque chose qui a été tout de suite géré quand les accélérateurs sont arrivés sur le marché. Les premiers accélérateurs sur PC et dans les consoles disposaient du recul des stations de travail, workstations, qui tournaient avec OpenGL où le lissage de Gouraud était courant. Aussi ce mode de lissage est relativement peu couteux à implémenter dans le hardware. Bien entendu, certaines de ces premières machines ont pris des raccourcis en n’implémentant pas la correction perspective, ou bien il y avait un nombre limité d’interpolateurs sans compter sur le fait que le calcul de l’éclairage par sommet devait se faire encore sur le CPU (avant l’arrivée des GPUs avec pipelines Transform and Lighting, TnL, complets).

Le premier Tomb Raider combinait textures simples et lissage de Gouraud

On notera que le faible nombre de polygones présents dans les premiers jeux en 3D favorisait l’utilisation de textures à celui de l’utilisation de l’éclairage par sommet pour amener des détails dans les scènes. En pratique on pouvait combiner les deux comme dans Tomb Raider, mais les textures étaient la plus grande source de détails et parfois véhiculaient toute l’information d’éclairage (utilisation des lightmaps dans d’autres jeux).

Le lissage de Gouraud dans son sens le plus strict est peu utilisé aujourd’hui, même s’il a fait les beaux jours des premiers jeux en 3D sur ordinateur. Il a été supplanté par la forme plus avancée du Lissage de Phong donc on parlera dans la prochaine partie. Dans un sens plus étendu, les GPUs actuels et les jeux modernes tirent toujours partie du concept d’interpolation de données sur un triangle, même si ce ne sont plus forcément des données de couleur directement mais des données qui sont ensuite utilisées pour calculer la couleur finale.

Par exemple, la formule qui est utilisée plus haut est la même formule qui sera utilisée pour interpoler les coordonnées de texture u et v (pour une texture “traditionnelle” comme la texture diffuse ou la texture de bump, de normale, d’opacité etc).

Flat Shading

À une époque lointaine du graphisme sur ordinateur les opérations de remplissage étaient très couteuses en cycles de processeurs. C’était l’époque où les graphismes étaient encore une niche de l’informatique, les calculs étaient réalisés sur des mainframes, gros ordinateurs centraux reliés à des terminaux, coûteux et dont les cycles CPUs étaient littéralement partagés par plusieurs chercheurs de manière parsimonieuse.

Pendant longtemps donc la méthode privilégiée pour remplir des polygones à l’écran (s’il y a avait un écran capable d’afficher des pixels), était de les remplir uniformément de la même couleur partout ce qui permettait de limiter les opérations mathématiques nécessaires pour l’opération.

En pseudo code ça pourrait donner cela :

pour chaque triangle
  calculer la couleur C du triangle
  pour chaque pixel(X,Y) appartenant au triangle
    couleur du pixel (X,Y) = C

La manière dont la couleur C est calculée est peu importante. Elle pourrait avoir été déterminé par un artiste et entrée manuellement, ou elle pourrait être calculée avec un calcul d’éclairage plus ou moins précis mais unique par triangle.

Voici une illustration du flat shading dans une scène simple :

Malgré son vénérable âge, la méthode de l’ombrage plat peut-être encore utilisée aujourd’hui. Dans le domaine du jeu vidéo, les puissances relatives des machines, même si des ordres de magnitude plus grandes que celles des mainframes où les premiers graphismes étaient calculés, n’ont pas toujours été capable de faire un grand nombre de calculs suffisants pour remplir tout un écran avec une vitesse d’affichage suffisante. On parle d’interactivité quand la vitesse d’affichage de chaque image est entre 10 images par seconde jusqu’à idéalement 60 images par seconde ou plus.

Les premiers jeux vidéos qui utilisaient des rendus polygonaux - par opposition au rendu bitmap ou basé sur des images déjà rendues en mémoire - ont donc souvent utilisé les méthodes des premiers graphismes off line, c’est à dire un rendu à base de lignes simples - fil de fer ou wire frame en anglais - ou un rendu facetté plat.

Rendu Fil de Fer de Atari BattleZone

Ombrage de quads plats par Sega Virtua Fighter

Aujourd’hui ces méthodes sont en partie rendues obsolètes par la puissance exponentielle des processeurs - notamment des accélérateurs 3D qui dominent le rendu des jeux contemporains. Mais il n’est pas exclu qu’un jeu ici et là décide de faire le choix artistique d’un rendu rétro à base de facettes ou de fils de fer uniquement parce que cela colle à l’atmosphère que les designers souhaitent donner au jeu. Rien n’exclut par ailleurs de faire un rendu qui ressemble à un rendu facetté mais avec en sous-main des algorithmes d’éclairage modernes loin de ce qu’aurait pu faire les jeux anciens qui sont pris comme référence.

Randy Pitchford opening Gearbox Community Day

Aliens Colonial Marines

D’abord un mot sur le fait que toutes les démos semblaient faites sur PC. Même si certaines semblaient jouées au pad. Aussi ce qui était discuté lors des panels était probablement une redite de l’E3 donc désolé si vous avez déjà lu ces infos.

Lors du panel on apprend que Gearbox a prévu de faire du coop lan, online, split screen (ce dernier uniquement sur console). Lors du coop les ennemis sont simplement plus difficiles à tuer, et cela s’ajuste dynamiquement suivant le nombre de persos jouables. Le joueur principale joue toujours le même perso et les autres joueurs peuvent arriver dynamiquement dans la partie pour faire les coéquipiers. Le scénario du jeu explique qu’un bataillon complet de marines est arrivé juste avant la partie donc pas de soucis au niveau du nombre de coéquipiers (jouables ou non).

Live concept art drawing Gearbox Community Day

La démonstration était jouée en direct. Ce n’était pas une cinématique (sauf au tout début qui montre notre vaisseau s’abimer sur la planète d’Aliens le second film de la série) par contre le joueur était probablement invincible (sauf à la fin). On dirait qu’il y a de nombreux moments scriptés : arrivee des aliens en vague, appuyez X pour glisser sous la porte juste avant qu’elle ne se ferme et que le gros alien fasse le bélier dessus. Prendre la tourelle, poser la tourelle juste a l’endroit marqué (avec le fantôme de la tourelle pour indiquer où la poser). D’après Randy Pitchford l’AI des aliens est très complète. Elle gère le mouvement dans le plafond, sur les murs et devrait bien réagir aux actions du joueur. Ceci dit la démo qui est jouée devant nous semble très très scénarisée. De nombreux événements semblent arriver à des moments prédéfinis (un coéquipier qui se fait embarquer par une voie d’aération ou un autre qui se fait déchiqueter par l’alien géant juste devant nous).

Il n’y a pas de photos ou de vidéos de la démonstration parce que Gearbox a prévenu à l’avance que toute tentative de capturer des images ou quoi que ce soit (ou faire mine de téléphoner ou texter) entraînerait l’expulsion directe de l’événement (avec passage obligé à l’hôpital “plaisante” Randy). Apparemment ils ne voulaient pas laisser cela à la chance, la salle étant dans le noir pendant la démo mais le personnel circulait dans les rangs avec des jumelles de vision nocturne.

PC gamer with 3D vision glasses at Gearbox Community Day

Honnêtement le jeu semblait plutôt beau. Le moteur est basé sur celui de l’Unreal Engine comme la plupart des jeux Gearbox mais le moteur de rendu a été totalement réécrit. Comme expliquait Randy, la base de l’UE comme le format de fichier, la structure C++, les outils etc sont très complets et n’ont pas besoin d’être réécrits mais pour Aliens ils voulaient un rendu bien particulier à base de très nombreuses lumières dynamiques qui apparemment n’était possible qu’avec une réécriture de la partie graphique.

20th Century Fox leur a donné une grande latitude pour réexplorer le mythe alien : il y a de nouveaux aliens mutants après une explosion nucléaire causée par la destruction de la station de terraforming, ils vont aborder les questions posées par le Space Jockey, ou se préoccuper du sort des compagnons de Ripley dans Aliens (ceux qui disparaissent dans le film mais dont on ne peut que deviner le sort). En même temps la série semble au point mort au cinéma après le quatrième film et les films Aliens vs Predator qui ont été plutôt mal accueillis (avec un reboot mystérieux en vue ?). Bref les questions abordées ou résolues dans le jeu pourrait ne pas avoir une grande importance s’il y a un reboot effectif de l’univers d’Alien (ou être simplement ignorés par de nouveaux films).

Lilith, Borderlands Cosplay

En parlant d’aliens mutants, un nouvel alien a été montré, il s’agit d’un alien géant gros comme un tyrannosaurus rex. Sa tête est coiffée d’une carapace impénétrable par les tirs normaux, ses interventions semblent donc très scriptées (trouver un abri rapidement, ou voir ses coéquipiers se faire déchiqueter etc).

On parle du jeu depuis longtemps mais d’après Gearbox c’est normal parce que même si le jeu a été annoncé par Sega dès 2007, lors de l’annonce il n’y avait pas une seule ligne de code écrite et donc le développement du jeu a démarré après cela. Ceci dit cela a l’air d’être un gros projet et on peut se demander s’il n’y a pas eu des temps morts et des revirements dans le développement.

Gearbox Fan at Gearbox Community Day

Randy insiste aussi beaucoup sur la version Wii U. Il était très excité que Nintendo utilise une vidéo créée à partir de leur early build sur Wii U lors de leur conférence à l’E3. Le jeu tourne déjà correctement sur Wii U, Nintendo leur avait donné accès au kit de développement bien avant l’annonce. Quelques nouveautés Wii U ont été annoncées, le mini écran portable servira de radar a aliens, ou fera apparaître la carte de la base (comme dans les films). Il y aura peut-être d’autres utilisations possibles. L’audience (probablement plutôt hardcore gamers) ne semble pas emballés par la Wii U au vu des réactions de la salle. Mais bon.

Brother in arms Furious Four panel with Randy Pitchford

Brother in arms : Furious four.

D’entrée de jeu, les gars de Gearbox reconnaissent qu’ils se sont sérieusement fait troller sur la nouvelle orientation de Brother in arms qui avait été annoncée quelques jours auparavant à l’E3. Contre toute attente il y a de nombreux fans des premiers jeux qui ne reconnaissent plus leur bébé “sérieux et épique”. Pour les rassurer sans doute, Randy est obligé de leur dire que BIA:FF est bien un épisode à part de la série et non pas la nouvelle orientation du jeu. Il dit tenir beaucoup à raconter la suite de l’histoire de Matt Baker (l’un des protagonistes des premiers Brother in arms) et que si l’on suit les événements de la deuxième guerre mondiale on sait qu’il y a encore matière à explorer pour faire encore une flopée de nouveaux jeux.

Le jeu lui-même ressemble à un mélange de films de Tarantino (”Kill.. Hitler”, violence graphique sans retenue, entrée en scène des personnages de manière super stylisée un peu à la japonaise/cinéma de hong kong avec leur nom surligné à l’écran), Borderlands (points a dépenser pour améliorer ses capacités, coop, humour), Bulletstorm. Ce dernier n’a probablement pas été cité comme inspiration par l’équipe du jeu parce que c’est la concurrence mais chaque mort d’ennemis s’accompagne d’un décompte de points et d’un commentaire sur le style de mise à mort et le sadisme est un point important du gameplay.

Ballroom Panorama at Gearbox Community day

Lors de la présentation on assiste à des phases de combats assez classiques dans des environnements plus ou moins ouverts. Des vagues d’ennemis chairs a canon qui servent de prétexte à expérimenter les armes les plus sadiques. Puis elles sont suivi de phases très scriptées au ralenti (Censées représenter l’effet de surprise dont bénéficie notre équipe.. Cela rappelle certaines séquences dans les Call of Duty). Pendant ce ralenti il faut effectuer une tâche en temps limité par exemple il faut tirer dans les lampes a huile pour les faire exploser ou tuer le plus d’ennemis au ralenti. L’exécution ou non de ces tâches ne semblent pas empêcher de continuer peut-être cela donne des points supplémentaires. Puis apres avoir tué toutes les vagues d’ennemis il y a un gros boss, sac à point, avec une attaque super puissante (mais un point faible). Le moment de tirer parti du coop.

Le jeu était joué en direct sur quatre écrans par quatre joueurs de l’équipe de Gearbox. L’une des armes du jeu projette un fer rouge en forme de l’état du Texas, gros fou rire dans la salle (on est a Dallas). Le joueur sur l’écran principal est Montana, un perso plus lent mais avec un gros machine gun. De temps à autre, il peut lancer une pioche (pickaxe) à distance et génère un Hourra ! de la salle à chaque fois que le pic atteint sa cible (”Bull’s eye”). A un moment il se bat a la tronçonneuse et coupe les ennemis en deux ou carrément en chair a pâté si le coup porté est critique. Une fois encore pas de photo ou vidéo disponible (les photos d’écrans diffusées lors de l’E3 semblent tirées du même niveau qui était montré ici).

Randy Pitchford and John St Jon at Gearbox Community Day

Le premier boss est un soldat nazi en jetpack (arme experimentale nazie). Il explose dans un feu d’artifice. Le deuxième boss est en armure de chevalier avec machine gun et un gros bouclier en metal ce qui le rend probablement inattaquable de front. Enfin un engin volant (Helico ? Dirigeable ?) qui entraîne dans sa chute la grande roue dans un effondrement de décor énorme. La destruction de décor la plupart du temps se fait de manière classique, beaucoup de choses sont destructibles mais ce qui n’est pas censé être détruit n’est pas affecté par le carnage ambiant (sauf suivant un élément scripté comme la destruction de la grande roue à la fin du niveau par exemple).

Ils ont apparemment choisi des armes plus originales que le jeu de guerre moyen : outre le fer rouge en forme du Texas, la pioche, il y a la hache de l’indien, le piège a loup dont une version (après upgrade) qui piège l’ennemi et le fait exploser avec une grenade après coup, la tronçonneuse (le retour d’une arme classique déjà présente depuis Doom), le lance flamme, électrocution. Ce qui est important c’est que ce soit fait avec sadisme.

Group of fans on Duke Nukem’s chair

Une session de questions/réponses suivaient, une fille présente dans l’assemblée suggère que l’on puisse choisir un personnage féminin. Apparemment Randy et les autres sont surpris et n’y ont pas vraiment pensé. Ils demandent a l’audience si ça leur plairait un personnage féminin ou si ça marcherait avec l’ambiance ultra violente du jeu. Dans tous les cas ils pourraient demander son avis à Chemicalia (qui travaille chez Gearbox) et qui pourrait leur faire une version féminine de leurs personnages (comme elle l’avait fait pour Team Fortress 2). Ils disent que le jeu étant déjà super avancé ce serait un gros changement d’apporter un nouveau perso donc ne veulent pas donner de faux espoirs, mais qu’ils ont déjà fait pire (en shippant DNF).

Duke Nukem Forever Panel at Gearbox Community Day

Duke nukem forever

Il y avait une séance de dédicaces avec Jon St John (la voix du Duke), Randy Pitchford (fondateur et PDG de Gearbox), Kristen Haglund (propriétaire de Triptych), Georges Broussard (3DRealms), Scott Miller (3DRealms), et un paquet d’employés de Gearbox ou de Triptych. Beaucoup de ces devs étaient dans l’aventure DNF depuis plus de dix ans. Broussard et Miller n’ont pas l’air de l’avoir trop mauvaise (je ne sais pas s’ils vont retrouver une partie de leur mise si DNF se vend bien). Triptych est la boîte qui a développé Duke Forever dans son garage avec les derniers assets de 3DRealms avant que la cavalerie Gearbox n’arrive.

Plutôt que de nous montrer le gameplay (puisque le jeu était jouable dans la pièce d’à côté), ils nous montrent une vidéo un peu inutile où les employés de Gearbox jouent en multijoueur avec des célébrités du net (je crois ?).

Signing of Gearbox devs with Britanni Johnson

Lors du panel, on soulève la question : est-ce que la fin du monde va empêcher la sortie de Duke nukem forever ? Ceci dit le jeu est sorti partout dans le monde sauf aux USA, la catastrophe est donc à moitié évitée. Mais ils croisent tous les doigts pour que la fin du monde n’arrive pas dans les jours a venir avant le mardi où le jeu doit sortir en Amérique du Nord.

Triptych a demarré le développement du jeu en fond propre sans salaires pendant six mois. Et c’est grâce à leur travail qu’ils ont eu une alpha jouable et que Broussard a ensuite pu aller proposer a Randy Pitchford de reprendre une partie du flambeau. Kristen Haglund la chef de Triptych accueillait les devs dans sa maison dans la suburb de Dallas. Les voisins avaient alerté la police qu’il y avait de l’activité suspecte, du va et viens beaucoup de voitures garées devant la maison dans la journée et en soirée (dont une Lamborghini.. celle de Georges Broussard). Ils se sont expliqué à la police (non ce n’était pas une crack house..) et quand les voisins ont appris qu’ils finissaient Duke Nukem Forever ils ont même proposé que les devs se garent devant leur trottoir (probablement une blague de la part de Kristen).

Bandit Psycho Midget Cosplay from Borderlands

D’après Pitchford l’humour dans Duke (et le nouveau brother in arms) fonctionne parce que tout le monde y croit, il n’y a pas un moment où un personnage se dit “ah on est dans une comédie”, c’est super sérieux pour eux et donc l’humour marche pour le spectateur. Ceci dit c’est probablement possible de faire l’argument dans les deux sens (cf écriture des Lucas arts à l’ancienne comme Monkey Island, etc).

Les devs donnent leurs citations favorites de Duke : “I had eggs for breakfast this morning, your mom had sausage”, “always bet on duke”, “What are you? Some bottom-feeding, scum-sucking algae eater?”. Apparemment c’est Kristen qui a écrit les choses les plus horribles de Duke 3D et Duke Forever (elle a joué le rôle de “writer” sur les deux jeux). Apparemment Duke a toujours fait hurler (les féministes et.. Fox News) mais ironiquement c’est une femme qui est derrière ces blagues machistes (et les femmes qu’il faut tuer dans le jeu).

Crowd in line for the Gearbox Community Day

Pendant la journée

La journée a commencé à 10 heures par une très longue queue (..”Well look at that, you can see my dick from here”) d’une heure. Heureusement le soleil ne tape pas encore super fort (et on est à l’ombre). La foule s’est déplacée en masse pour ce premier Community day. Des gens sont venu des quatre coins des US et même du Canada pour y assister. Il y a apparemment de nombreux fans de Gearbox et puis il y a l’attrait.. du Duke. Les panels occupent la majeure partie de la journée, et il y a un “mini musée” de memorabilia liée à Gearbox : jeux en démo Half Life, Samba de Amigo, Brother in arms, des trophées et récompenses, des concept arts pour les jeux Aliens (par Syd Mead), etc. Et une zone de démos où l’on peut jouer à Duke Nukem Forever en Nvidia 3D Vision (Nvidia était partenaire de l’événement ainsi que Logitech).

Entre les panels ils donnent des souris gratos, un netbook HP et une carte graphique Nvidia édition DNF. Les questions posées sont impossibles (pour moi). Mais les vrais fans présents sur place connaissent le background des jeux par cœur et donc n’ont aucun mal à répondre. Celui qui a gagne la carte graphique devait twitter Georges Broussard le plus rapidement possible (avantage a ceux qui ont un smartphone et un compte twitter et ceux qui suivent Georges Broussard sur Twitter).

Very young fan of Gearbox

J’ai eu aussi l’occasion de discuter avec un character artist qui bossait en temps réel sur un concept art suivant les thèmes choisis par l’audience (”guns, hot alien chicks, boobs, cheese, monster”). Il a apparemment bossé dans les comics avant de vouloir absolument bosser dans les jeux vidéo et donc d’accepter de dessiner des interfaces pour Borderlands avant de pouvoir faire ce qu’il voulait à savoir du character design. C’était un thème assez présent pendant la journée, Gearbox c’est la meilleur boîte du monde, mes meilleurs copains bossent à Gearbox et on n’a pas de problème à bosser super dur pour que nos jeux réussissent. Ceci dit sur la quantité de travail fourni, il n’est pas rare de voir les devs déconner dans la journée (Nerf, parties en réseau, air hockey) et bosser tard le soir (croiser des gens qui bossent à minuit). Reste à voir si les gens sont productifs sur toute la longueur ou se sentent obligé de faire acte de présence pour ne pas trop se démarquer.

Malgré l’aspect “mature” des jeux présentée, l’ambiance est limite “family friendly”, pas de gros mots (Randy se reprend à plusieurs fois) et les seuls seins découverts sont dans le jeu DNF. Il y a quelques enfants présents. La soirée était censée être limitée aux plus de 21 ans (alcool présent) mais des enfants dont le fils de Randy était présent et j’ai cru voir passer quelques jeunes filles qui n’avaient pas l’air d’avoir 21 ans passé. La soirée était gratuite et attirait encore beaucoup plus de monde que dans la journée. Je n’ai pas pu prendre de photos pendant la soirée, apparemment mon DSLR d’entrée de gamme est une “caméra de pro”. (J’ai eu des retours variables sur des gens qui ont pu entrer avec leurs appareils photos). Ceci dit l’ambiance était plutôt bonne (plusieurs numéros musicaux dont le partenaire de Will Smith lors de la période “prince de Bel air”, Dj Jazzy Jeff).

Duke Nukem Happy Ending Palladium Ballroom Dallas

Quelques photos

Le problème

La version 64 bits de Windows ne fonctionne que sur des machines dont le processeur principal supporte le nouveau jeu d’instruction x86-64 étendu d’AMD (cela marche aussi sur une grosse partie des processeurs d’Intel). Bien entendu c’est une majorité du marché des PCs mais il y a tout de même suffisamment d’exceptions (certains processeurs pour machines windows ultra portables, ou simplement des machines plus anciennes) pour que Microsoft décide de conserver une option 32 bits.

Pour le reste du monde, c’est à dire ceux qui ont un PC récent qui a un processeur 64 bits se pose le problème du choix de la version de l’OS.

Si j’ai moins de 4 GB de RAM, je suis OK ?

En théorie, le problème de 64 bits vs 32 bits n’est pas exactement un problème de RAM physique malgré ce que l’on peut entendre ici et là. Le problème est lié à l’espace d’adressage virtuel, c’est à dire combien d’adresses différentes un simple processus peut utiliser. Bien entendu pour le grand public on pourrait simplifier en disant que plus il y a de RAM physique alors plus les adresses seront utilisées rapidement. C’est d’ailleurs ce que fait Microsoft en partie en limitant arbitrairement la quantité de mémoire physique adressable suivant la version de Windows qui est vendue. Mais AVANT l’arrivée des extensions x86-64 d’AMD, il était possible d’ajouter plus de 4 GB de RAM physique et certains OS (y compris dans la famille Windows) pouvait les adresser via des pointeurs physiques étendus. Le processeur va prendre une adresse virtuelle et la convertir en adresse physique de manière automatique ce qui permet aux applications d’exploiter le mode d’adressage plat : l’adressage plat exposé aux applications peut être limité à 32 bits alors qu’en sous-main l’adressage physique (vers la puce de RAM) peut utiliser plus de bits.

Mais, la situation actuelle étant ce qu’elle est sur Windows Seven, il a été décidé par Microsoft que les systèmes voulant exploiter plus de 4GB de mémoire physique devront installer la version 64 bits de l’OS.

Pour résumer si vous avez 2Go ou 1Go de mémoire RAM vous pouvez bénéficier de la version 64 bits de l’OS (voir les arguments ci-dessous). Mais si vous avez plus de 4Go de RAM il vous FAUT installer la version 64 bits sinon l’OS ne voit pas plus que 4Go et donc vous avez acheté de la mémoire supplémentaire pour rien (ou en prévision, mais sachant que le prix de la RAM ne fait que descendre c’est un mauvais investissement).

Quels choix ?

Ce n’est pas vraiment de la segmentation de marché à proprement parler, mais plutôt de la simplification de l’offre. En effet malgré que la version boîte de Windows Vista ne contient qu’une seule version (à l’exception de la version Ultimate qui contient les deux versions) et donc nécessite de faire un choix à l’achat, Microsoft propose à quiconque de commander une version sur DVD de la version 64 bits (ou 32 bits dans le cas contraire) sur leur site Windows Vista alternate media. Une clé d’enregistrement Windows Vista 32 bits est également valable pour la version 64 bits donc il est tout à fait possible de changer d’avis après l’achat (lors de l’upgrade de la RAM par exemple).

Cette politique va être étendue à Windows Seven, même si l’on peut espérer que plus de gens choisissent l’option 64 bits dès l’achat.

Résumé des arguments

Les problèmes d’adressage virtuel peuvent paraître assez abscons à la majorité des gens, pourtant c’est un problème tout à fait réel et qui peut arriver bien avant que votre PC n’embarque 4Go de RAM.

Pour la population des joueurs de Nofrag, cela se pose particulièrement parce que le problème est accru dans les jeux.

Le problème des ressources MANAGED

Le premier problème est Direct3D 9 et l’utilisation des ressources MANAGED. Dans les temps anciens où Direct3D était encore en développement, l’un des soucis de Microsoft était la concurrence de OpenGL et dans OpenGL l’utilisation des ressources était transparent, c’est à dire qu’il n’y avait pas à proprement parler à appliquer de gestion des ressources dans les applications, tout était fait en interne dans le driver pour que la carte graphique ait accès à la texture lambda lors d’un tracé. Direct3D a donc (mais seulement partiellement) simulé cela avec le pool de textures (et vertex buffers etc) MANAGED (”géré dynamiquement”). Le runtime (la dll chargée de faire interface entre l’application D3D et le serveur) devait donc stocker une copie de la texture dans son propre tas (HEAP), ceci afin de pouvoir décider lors du tracé de supprimer une texture de la mémoire vidéo pour la remplacer par une autre et ceci de manière transparente pour l’application (cela permettait également de restaurer les ressources qui avaient été perdues lorsque le device était redémarré). MAIS cette ressources existait aussi en mémoire vidéo la plupart du temps, et certaines applications bien intentionnées gardaient également une copie dans leur propre tas (HEAP). Ces copies supplémentaires résident en mémoire utilisateur (les mettre en mémoire kernel si cela avait été possible n’aurait fait qu’agraver le problème).

En soi cela n’apparait pas forcément comme un problème critique (juste une utilisation non optimale). Après tout en utilisation normale ces ressources n’ont pas à être en mémoire physique et peuvent être déchargées sur le disque (ce qui se passe le plus souvent puisqu’elles n’étaient accédé qu’en cas de redéploiement en mémoire vidéo). On peut donc avoir 1Go de RAM au total et 2Go de ressources chargées sans problème.

Ce qui le rend critique c’est que le système de déchargement sur disque et l’adoption d’un modèle d’adressage “plat” par l’application nécessite que ces ressources même déchargées de la mémoire aient une adresse virtuelle constante. Cette adresse virtuelle constante va polluer l’espace d’adressage. Faites le calcul : une carte vidéo haut de gamme embarque 1Go de mémoire VRAM et peut aussi utiliser la mémoire de son hôte (via le bus PCI Express). Une application X décide d’allouer la majorité de ses ressources textures, vertex buffers etc, dans le pool MANAGED. Ces textures vont donc non seulement occuper 1Go ou plus en mémoire vidéo, mais également 1Go ou plus dans le tas du runtime et donc occuper de manière permanente 1Go ou plus de l’espace d’adressage de l’application. Sachant que cet espace d’adressage sous XP et Vista et Seven 32 bits est limité à 2Go (les adresses 32 bits dont le bit le plus haut n’est pas 1), cela laisse peu de latitude pour ce qui suit.

Une application qui voudrait tirer partie du maximum de sa mémoire disponible et qui doit être compatible avec les OS 32 bits de Microsoft a donc fortement intérêt à n’allouer que des ressources dans le pool DEFAULT de direct3D. D’ailleurs le pool MANAGED a totalement disparu de Direct3D 10 (et Direct3D 11). Il a été remplacé par un meilleur système qui fait qu’une texture dans le pool DEFAULT et dans une application programmée pour Vista (D3D9ex) sera maintenue valide quelque soit le sort de l’application (alt tabbed, etc.).

Ressources verrouillables

Le second problème (qui a heureusement été fortement réduit grâce à un hotfix de Vista après sa sortie) était la manière dont Vista gérait les ressources en mémoire vidéo.

En théorie une ressource en mémoire vidéo (gérée par le driver et visible par la carte graphique) n’a pas à occuper de l’espace d’adressage de l’application (le précieux user memory address space). Au pire lorsque l’application a besoin (ou le driver) d’y accéder en lecture ou écriture avec le processeur central ou CPU, le driver va effectuer un remapping c’est à dire allouer une plage d’adresse temporairement et pour cette ressource uniquement. On dit que cette ressource est verrouillée (”locked”).

Vista a introduit une gestion améliorée de la mémoire vidéo qui passe désormais par l’OS. Cette gestion améliorée rend possible le déchargement de la mémoire vidéo en mémoire non-vidéo (non accessible par la carte graphique) ou sur disque. C’est une certaine façon une amélioration du POOL MANAGED d’antan puisque contrairement à MANAGED une seule copie de la ressource existe à un moment donné. Et cela permet en théorie d’avoir un nombre illimité de ressources graphiques (ou limitée par la taille du disque dur..). Mais la toute première version de Vista (RTM) allouait systématiquement un bout de Virtual Address space à ces allocations. Et bien entendu, ce bout de virtual address space rogne sur les 2Go disponibles dans l’OS 32 bits. Pour une carte graphique qui a 1Go de VRAM (plus la partie qui peut-être prise sur la mémoire hôte via le port PCI-Express), utiliser toute la mémoire veut dire que 1Go de l’espace d’adressage ou plus est utilisé. L’erreur est encore plus critique lorsque plusieurs GPU existent dans le système (config SLI). Chaque texture est dupliquée sur chaque GPU et donc sur une config SLI de cartes 1Go chacune avec la version RTM de windows 32 bits il était mathématiquement impossible d’allouer des textures (et vertex buffers etc.) pour remplir la mémoire vidéo dans une seule application. Plusieurs applications peuvent se partager la mémoire vidéo sans problème par contre.

Les jeux sortant à la même époque que Vista plantait donc fréquement au lancement ou au cours du jeu et le plus souvent de manière assez étrange/inexpliquée : retour sous le bureau, bsod, “XXX a causé une erreur et a du être redémarré”, etc.

Le Hotfix de Vista 32 bits puis la version SP1 a fortement réduit l’importance de ce problème. Ce qu’a fait le hotfix c’est de supprimer la nécessité d’allouer une plage d’adresses virtuelles pour toutes les ressources sauf celles qui devront être “verrouillée” par l’application ou le driver. Le driver applique donc une heuristique pour déterminer les ressources qui peuvent être verrouillées ou au pire fait faire une copie par le GPU d’une ressource non verrouillable vers une ressource verrouillable s’il a fait une erreur de prédiction (ou si il y a trop de ressources verrouillables en cours ce qui risquerait de poser le problème que l’on cherchait à éviter en premier lieu).

Fragmentation

La fragmentation de mémoire physique est quasi inexistante. L’adressage virtuel fait que une ressource peut être allouée dans plein de pages mémoires éparpillées en RAM ou sur disque et l’application n’y voit que du feu.

Cependant, cet adressage virtuel se fait, lui, via un pointeur qui a un nombre de bits limités, et donc ne peut prendre qu’un nombre fini de valeurs (l’équivalent de 2Go de mémoire allouée en mode 32 bits). Si l’on ne fait pas attention une poignée d’allocations placées à des endroits stratégique peuvent empêcher une grosse allocation de se faire alors que la mémoire disponible semble indiquer qu’il n’y a aucun problème.

La bonne nouvelle c’est qu’une application A ne peut pas polluer l’espace d’adressage d’une application B et que donc le problème peut être traité en interne. Mais il n’y a pas tant de bonnes solutions à ce problème : limiter la somme des allocations pour laisser toujours un espace suffisant pour une grosse allocation (ce qui ne peut être garanti sauf avec un allocateur quasi statique), se limiter a des petites allocations (ce qui excluerait par exemple le mapping de gros fichiers du disque en mémoire), offrir la possibilité de réorganiser la mémoire et les pointeurs à la volée (plus facile à dire qu’à faire même si certains le font par obligation), forcer l’application à redémarrer de temps en temps (ce qui peut être ok si le problème de fragmentation arrive après une longue période d’utilisation plus longue que la session de jeu standard). Bien entendu quelle que soit la solution choisie ce n’est que repousser le problème jusqu’au jour où l’on aura vraiment besoin de plus de 2Go d’adresse même avec une fragmentation zéro.

Mais les OS 64 bits existent alors pourquoi se compliquer la vie ? (oui oui.. je sais pourquoi.. pas la peine de répondre)

Applications 32 bits sur 64 bits

Le passage aux OS 64 bits est facilité par la compatibilité des applications compilées pour le 32 bits avec l’OS 64 bits. Bien entendu, une telle application ne peut tirer partie des avantages du 64 bits ou alors uniquement de manière temporaire en utilisant le flag /LARGEADDRESSAWARE à la compilation. Cela indique que l’application peut utiliser l’équivalent de 4Go d’adresses à la place de 2Go. Ce qui donne quelques années de répit sur l’inévitable.

D’ici peu, les applications seront soit compilées en une version 32 bits et une version 64 bits, soit compilée en version 64 bits uniquement. Certaines applications professionnelles (CAD et autres) sont dans cette situation depuis quelques temps. Les jeux semblent être les prochains sur la liste par leur utilisation forcenée des ressources (déjà les “éditeurs de contenu” du jeu ont fait la migration, le client va bientôt y passer).

Bien entendu, on peut continuer à cohabiter avec les applications 32 bits encore un moment. Après tout une application peu gourmande peut n’avoir aucun besoin de plus de 4Go et en plus peut bénéficier en perf de l’utilisation de pointeurs 32 bits à la place de 64 bits (si elle stocke beaucoup de pointeurs en mémoire). Et la suppression des ressources managed, le hot fix pour adresse virtuelle, et quelques efforts de la part des programmeurs devraient rendre beaucoup d’applications encore largement utilisable sous 4Go d’espace d’adressage pour encore un peu de temps.

Windows Seven 64 bits ou 32 bits

De mon côté aucune hésitation, toutes mes installations Vista sont déjà 64 bits. J’ai la chance de n’avoir aucun problème de compatibilité depuis quasiment 2 ans (le passage xp à vista semble un plus gros problème que le passage vista 32 bits à vista 64 bits de mon point de vue). Les drivers 64 bits doivent faire l’objet du même soin que 32 bits (logo WHQL) et les auteurs d’application qui ne respectent pas la portabilité sont de plus en plus rares (games for windows par exemple a pour critère la “compatibilité” avec l’OS 64 bits) : en général ce sont les “protections” intrusives trop anciennes et pas mises à jour qui posent problème, les jeux récents ayant fait l’objet d’un test sur machine 64 bits.

Si on lit entre les lignes, avec Direct3D 11, on dirait que Microsoft plaide coupable pour certains choix qu’ils ont faits avec Direct3D 10. C’est paradoxal, parce qu’au premier abord Direct3D 11 sera fondamentalement proche de son prédécesseur tout en étant dramatiquement différent. Comment est-ce possible ?

Changement de cap

Direct3D 11 représente un changement de cap important de la part de Microsoft. Enfin au moins pour cette version-ci, on ne peut pas encore prédire si cette bonne volonté sera renouvelée avec la version suivante de l’API.

On se souvient que Direct3D 10 avait été présenté dès ses débuts comme lié à Windows Vista, choix qui a été vivement critiqué par les développeurs qui n’avaient pas la possibilité de développer prioritairement pour Vista. Loin d’être la killer app qui allait faire passer à Vista, cela a rallongé artificiellement la vie de Direct3D 9. On pouvait craindre que Direct3D 11 soit également lié à Windows Seven. Heureusement, Microsoft a entendu les développeurs et les clients cette fois-ci en faisant en sorte que Direct3D 11 tourne également sous Vista, mais pas sous XP. Verre à moitié vide ou à moitié plein, à vous de voir. Le fait est que si les développeurs démarrent le développement d’un nouveau moteur après le lancement de Direct3D 11, lorsque le moteur sera fini, il est possible que Vista et Seven aient une base installée suffisante pour pouvoir en faire une base exclusive.

Mais est-ce que ce sera suffisant pour que les développeurs choisissent la route Direct3D 11 uniquement ? Peut-être ou peut-être pas mais la décision sera aidée par ce qui suit.

L’un des autres reproches fait à Direct3D 10 était le fait que l’équipe DirectX avait préféré faire table rase du support matériel et redémarrer à zéro en supprimant les CAPS bits et les fonctionnalités inutilisées afin d’augmenter l’efficacité de l’API. Le résultat, bien entendu, c’est qu’à la sortie de Direct3D 10, une seule carte supportait l’API, c’était la GeForce 8. L’inertie du marché étant ce qu’elle est, un jeu vidéo pour être viable doit aussi tourner sur les cartes plus anciennes du marché : Radeon 9X/XX/X1, GeForce 5/6/7, Intel integrated, etc. Le fait est qu’un développeur de jeu avait beaucoup plus d’intérêt à développer un jeu exclusif Direct3D 9 qu’un jeu exclusif Direct3D 10 en 2009.

Gros changement : Direct3D 11 de son côté tournera sur toutes les cartes Direct3D 9 avec support WDDM (GeForce Fx/Radeon 9×00 dans les plus anciennes cartes supportées). Certes, c’est loin d’être parfait (le support WDDM exclut pas mal de vieilles cartes graphiques) mais c’est déjà beaucoup mine de rien. L’équipe DirectX a donc dû casser la belle interface Direct3D 10 pour y ajouter des « niveaux de compatibilité matérielle ». Ainsi, à la création du device Direct3D, il y a la possibilité de sélectionner les niveaux de compatibilité D3D_FEATURE_LEVEL_11_0, D3D_FEATURE_LEVEL_10_1, 10_0, 9_3, 9_2, 9_1.

Étant donné la parenté évidente de Direct3D 11 et Direct3D 10, supporter l’un avec l’autre n’est pas très surprenant. Mais Direct3D 9 et Direct3D 10 sont vraiment différents de prime abord. En pratique ce sera une concession à l’efficacité et l’exhaustivité (il ne sera pas possible de tout faire ce qui était possible sous Direct3D 9 avec ce nouveau type de device). Difficile de savoir comment sera le support en pratique et si cela sera largement adopté.

C’est une main tendue, d’une certaine façon, de Microsoft aux développeurs mais le but ultime c’est bien sûr d’accélérer l’acceptation de la nouvelle interface de programmation et l’acceptation des nouveaux OS par effet mécanique (lorsque tous les jeux seront exclusifs à ces OS, objectif a long terme).

(Ré-)Introduction de la tessellation

Le mot tessellation vient du mot latin tessella qui a donné tesselle, c’est-à-dire le carreau dont est constitué une mosaïque. C’est une technique dite de « subdvision » où une surface est décrite de manière grossière et est raffinée petit à petit en rajoutant du détail géométrique.

La tessellation a de nombreux avantages. La forme non tessellée prend moins d’espace en mémoire et est moins lourde à manipuler : un artiste peut travailler sur une forme non tessellée et demander au logiciel de création de contenu (DCC) de rajouter des détails automatiquement avec une simple interpolation ou depuis une texture de détail (displacement mapping). De même, en temps réel, un jeu peut faire des calculs complexes sur la forme grossière avant d’envoyer le tout à la carte graphique. Les calculs complexes sont donc plus légers et l’affichage se fait sur un modèle agréable à l’œil sans trop d’arêtes vives. C’est la théorie.

Pour ceux qui suivent l’industrie graphique depuis quelque temps, la tessellation est un peu le serpent de mer de la 3D temps réel. Loin de moi l’idée d’être exhaustif mais voici un résumé. L’API graphique OpenGL proposait les evaluators. Ce sont des surfaces de Bézier (Bézier surface patch). Direct 3D 8 avait introduit de son côté deux types de surfaces « subdivisables » aussi appelées high order surfaces (par opposition aux triangles qui sont des surfaces d’ordre 1 dans la classification des surfaces polynomiales), les R/T patches et les N patches. Ce sont aussi des variations sur les surfaces et courbes de Bézier (la rapidité de l’évaluation des surfaces de Bézier est imbattable).

Si les cartes sorties avec Direct3D 8 les ont mis en avant, les cartes sorties après Direct3D 9 ont arrêté de les supporter. Le support des high order surfaces n’a donc été qu’une parenthèse dans l’histoire de Direct3D. La faute, sans doute, à un intérêt relatif réduit, à une faible flexibilité de l’implémentation, au manque du support du displacement mapping (qui a pourtant fait une rapide apparition sur la Matrox Parhelia mais qui n’a jamais été exposé sous Direct3D), à la difficulté à adapter le pipeline de production pour le support de la même géométrie avec et sans tessellation et probablement aussi le fait que la fonctionnalité X fonctionnait chez le vendeur de carte graphique X et la fonctionnalité Y fonctionnait chez le vendeur de carte graphique Y ce qui en limitait l’audience. Le reste c’est de l’histoire ancienne.

La tessellation a ensuite fait sa réapparition dans un contexte particulier : le Xenos (ou C1) de ATI devait supporter une forme de tessellation mais la puce était réservée à la Xbox 360 (ATI préférant sortir la plus traditionnelle Radeon X1800 sur le marché PC).

Dans les premiers documents parlant de DirectX Next (autre nom de Direct3D 10 dont le développement avait commencé après que Direct3D 9 avait été lancé), Microsoft avait présenté une de ses idées pour le nouveau pipeline graphique post Direct3D 9. Dans cette vision il y avait plusieurs vertex shaders (un pour chaque niveau de raffinement de la géométrie), une unité de tessellation (dont le fonctionnement n’a jamais été défini), un geometry shader et un pixel shader. Il est important de noter qu’initialement, le geometry shader n’avait pas pour but de faire de la subdivision de géométrie, cette tâche étant assignée à l’unité de tessellation. Au final on sait ce qu’il en est advenu. Des nouvelles unités imaginées au départ, seul le geometry shader a survécu, et le vertex shader est resté unique en amont du geometry shader. Le geometry shader n’était toujours pas conçu pour faire de la subdivision et les tentatives pour lui faire effectuer cette tâche ont échoué (les performances sont abyssales lorsque l’expansion des données géométriques est trop importante comme dans le cas d’une subdivision).

Tessellation - détails d’implémentation

Le nouveau pipeline Direct3D 11 ressemble à ça :

input assembler (IA) -> vertex shader (VS) -> hull shader (HS) -> tessellator (TS) -> domain shader (DS) -> geometry shader (GS) -> rasterizer (RS) -> pixel shader (PS) -> output merger (OM).

En gras sont les unités que Direct3D 11 a rajoutées. Il y a donc deux nouveaux types d’unité de shader (hull et domain) et une unité « fixe » appelée tessellator (tesselleur ? tessellateur ? À vos dicos !).

En gros, l’IA va lire les patches depuis le vertex buffer, chaque patch est décrit par le nombre de sommets qui constituent ce patch (de 1 à 32), ce qui permet de mixer plusieurs types de patches dans un seul draw call (ou récupérer des données générées par une passe précédente). Puis le vertex shader va faire des transformations sur ces sommets. S’il faut faire de l’animation lourde (blendshapes, simulation physique), c’est le moment de le faire. Le VS lit toujours un seul sommet en entrée et écrit un seul sommet en sortie. Le VS ne change pas de sémantique qu’il travaille sur des patches, des points, des triangles, etc. Les sommets ne sont - pas encore - des points de contrôle, du moins pas dans leur base définitive. On va voir par la suite comment interpréter ces sommets.

pd3dDeviceContext->
IASetPrimitiveTopology( D3D11_PRIMITIVE_TOPOLOGY_32_CONTROL_POINT_PATCHLIST );
pd3dDeviceContext->DrawIndexed(NumIndices, 0, 0 );

On voit ci-dessus qu’il faut indiquer à l’IA (input assembler) que la topologie des sommets à transformer constitue un « patch » de 32 points (ou tout nombre inférieur). Les sommets qui constituent le patch sont passés en indice et envoyés à la carte via DrawIndexed(). Dans ce cas, il y a 32 sommets « potentiels » : ces sommets sont transformés puis sont passés en argument à la phase suivante.

Le HS est appelé une seule fois par patch. Mais l’une des particularités du HS est d’avoir des phases au nombre de deux. Ces phases ressemblent à des shaders indépendants dans le langage de description HLSL mais sont attachées toutes ensembles, de manière atomique, au hull shader. L’intérêt d’avoir des phases est la possibilité de séparer logiquement les parties indépendantes du hull shader et donc de donner l’opportunité au matériel d’exécuter ces phases en parallèle dans des unités de calcul séparées. Ces phases peuvent être invoquées plusieurs fois.

Quelles sont donc les phases en question ? La première est le calcul des constantes par patch (Hull shader path constant phase). C’est là que l’on va calculer le niveau de tessellation par exemple. Le niveau de tesselation (tesselation factor) est calculé pour chaque bord du patch. Calculer le facteur par bord de patch permet de faire en sorte que deux patches adjacents qui ont les mêmes sommets sur les bords aient également le même niveau de subdivision sur leur bord commun. C’est primordial pour éviter les trous et les superpositions, on parle dans ce cas de rasterisation étanche (watertight) lorsque tous les pixels d’une zone rasterisée sont couverts une fois et une seule fois. La deuxième phase est la phase des points de contrôle (Hull shader control point phase). Cette phase peut lire toutes les inputs du patch (les 32 sommets) et est exécutée une fois par point de contrôle déclaré.

[domain("quad")]
[partitioning("integer")]
[outputtopology("triangle_cw")]
[outputcontrolpoints(16)]
[patchconstantfunc("SubDToBezierConstantsHS")]
BEZIER_CONTROL_POINT SubDToBezierHS( InputPatch p,
uint i : SV_OutputControlPointID,
uint PatchID : SV_PrimitiveID )
{
}

Par exemple dans le code ci-dessus, on a la déclaration du hull shader et la fonction appelée pendant la phase des points de contrôle. Les parties entre crochets représentent les paramètres que l’on passe à l’unité de tessellation fixe, à savoir que le domaine du patch est le quad (qui pourrait être un triangle ou une ligne), le partitionnement (division du domaine) se fait avec des nombres entiers, que la topologie sortante est composée des triangles dont les sommets sont donnés dans le sens des aiguilles d’une montre (clock wise), qu’il y a 16 points de contrôle à générer (la fonction SubDToBezierHS sera donc appelée 16 fois) et la fonction qui sera appelée pour la phase des constantes par patch est SubDToBezierConstantsHS(). Cette fonction-là sera appelée une seule fois par patch.

La fonction ci-dessus prend comme argument InputPatch<>. C’est un attribut généré par le système qui contient tous les sommets que l’on a déclarés qui appartiennent au patch en question (souvenez-vous : assemblés par l’IA et transformés par le VS). Il peut y avoir plus de sommets dans ce patch (MAX_POINTS) que de sommets déclarés en sortie (outputcontrolpoint(16)) tout simplement parce que l’on pourrait, par exemple, avoir envie de passer les sommets directement adjacents au patch pour améliorer la qualité de la future interpolation (watertight, continuité C0/C1, etc.).

Une fois le hull shader exécuté, le tessellator entre en action. Il va générer le « domaine » en question sans lire les points de contrôle. En fait son rôle est limité au minimum. Si le domaine est « patch », il va générer un carré paramétré par U,V entre 0 et 1, et le nombre de points générés sur ce carré va dépendre des tessfactors écrits par le HSPCH ci-dessus.

Pour chaque sommet généré par le tessellator, on va donc appeler la fonction déclarée pour le domain shader.

[domain("quad")]
DS_OUTPUT BezierEvalDS( HS_CONSTANT_DATA_OUTPUT input,
    float2 UV : SV_DomainLocation,
    const OutputPatch bezpatch )
{
}

La fonction est précédée de la déclaration du domaine, ce qui est nécessaire pour associer le DS avec le HS correspondant (si ce n’était pas le cas, le DS risquerait de ne pas bien comprendre les arguments qu’on lui fournit). L’un des arguments de BezierEvalDS est le nombre U,V qui est celui généré par le tessellator par ce point. Cela ne veut pas dire que les coordonnées de texture sur ce point doivent obligatoirement varier entre 0 et 1, c’est juste une manière d’indiquer au DS où il se trouve sur le patch. Les coordonnées de texture, la couleur, les normales, les tangentes sont, elles, générées à l’intérieur de ce shader en prenant la partie constante HS_CONSTANT_DATA_OUTPUT qui arrive directement du HS sans passer par le tessellator et en la combinant avec le U,V généré. Par exemple, on peut imaginer que la coordonnée de texture Tex0 est une simple transformation affine des U,V par une matrice qui a été passée au préalable dans HS_CONSTANT_DATA_OUTPUT. Cette matrice a été calculée à partir des coordonnées Tex0 qui alimentaient le HS via ses points de contrôle. Voilà comment vous feriez en pratique (la matrice est ici décomposée en bilerp ou interpolation bilinéaire pour des raisons de simplicité) :

// bilerp the texture coordinates
float2 tex0 = input.vUV[0];
float2 tex1 = input.vUV[1];
float2 tex2 = input.vUV[2];
float2 tex3 = input.vUV[3];
float2 bottom = lerp( tex0, tex1, UV.x );
float2 top = lerp( tex3, tex2, UV.x );
float2 Tex0 = lerp( bottom, top, UV.y );

Ce n’est pas la seule solution possible, il y a d’autres interpolations possibles par exemple pour les normales (l’interpolation bilinéaire n’a pas forcément la qualité désirée). Mais ne nous attardons pas là-dessus aujourd’hui.

Le résultat du domain shader est donc les sommets des triangles (ou des segments) qui composent notre patch de Bézier après son interpolation. Ces sommets sont ensuite envoyés au Geometry shader qui les traite comme s’ils venaient directement du vertex buffer. On a bien des triangles (ou segments) indépendamment de la nature du patch utilisé en amont (triangle ou quad ou ligne), tout simplement parce que c’est la seule primitive qu’accepte le rasterizer.

Subdivision avec Direct3D 11

Tessellation - Limitations

Il y a plusieurs choses que l’on peut noter à partir des documentations qui ont été postées sur le web. On a parlé de surfaces de Bézier ci-dessus mais on peut voir que l’on n’est pas limité à ce type de représentation, la partie fixe se contente de générer une paramétrisation (u,v). Si on est capable d’évaluer une surface à partir d’une paramétrisation 2D alors il est possible d’évaluer cette surface avec notre unité de tessellation. Bézier est la sous-partie des surfaces paramétrées qui s’évaluent par des fonctions polynomiales des U,V.

Bien entendu, toutes les descriptions de surfaces ne se prêtent pas à la paramétrisation. Sans aller jusqu’aux fractales (un beau contre-exemple), des descriptions continues mais récursives comme les surfaces de subdivision avec points particuliers ne sont pas facilement paramétrables à proximité des points particuliers (c’est le « facilement » qui est important ici). Certaines courbes comme les courbes de Bézier sont trivialement paramétrables (même si on peut leur donner une définition par subdivision : cf. algorithme de Casteljau). L’exemple donné dans les présentations de Microsoft et de NVIDIA utilise une approximation de l’algorithme de Catmull-Clark par des patches bicubiques de Bézier. Et si l’on en croit les exemples donnés, l’aspect visuel est tout à fait satisfaisant. Donc, sauf si vous partez dans des ressources fractales, il est probablement faisable d’approcher vos surfaces avec des fonctions plus simples, voire de rester dans les fonctions bicubiques. La complexité de l’algorithme de subdivision lui-même est probablement secondaire si l’on peut générer des surfaces continues deux fois (au moins visuellement) et lire des détails depuis une texture.

La performance est en question. Quel niveau de tessellation peut-on attendre ? Est-ce que le simple fait d’activer l’unité de tessellation va faire chuter le frame rate avant même que l’on ait généré le premier sommet supplémentaire ? Question difficile à répondre de prime abord avant d’avoir vu le premier matériel tourner. Tout d’abord une évidence : il y a deux unités de shaders supplémentaires qui vont effectuer un travail non nul sur les unités de calcul (que se partageaient déjà le vertex/geometry/pixel shader). Donc il est évident qu’en cas de goulet d’étranglement sur ces unités de calcul, la performance globale risque de baisser. De plus, qui dit tessellation, dit génération d’un grand nombre potentiel de triangles supplémentaires, ces triangles seront plus petits (rendant la rasterisation moins efficace ?) et encombreront l’unité de setup/clipping, etc. augmentant la possibilité de goulet d’étranglement durant cette étape.

Bien entendu ce coût en performance sera contrebalancé par l’augmentation possible du visuel. Si les performances des nouvelles puces suivent, on aura une augmentation décente de la qualité d’image. On ne peut pas comparer des pommes et des oranges mais une augmentation comparable de la qualité d’image via un rendu « classique » sans tessellation aurait été coûteux en mémoire (stockage temporaire ou permanent des modèles), mais aussi du côté du CPU (envoi des données géométriques, voire tessellation partielle sur le CPU), et même coûteux lors de la transformation et de l’éclairage (vertex shader).

Un bon point cependant, même dans le cas où son coût le limite à des scénarios limités au début, il est probable que ce support ne disparaîtra pas dans le futur comme celui de la tessellation dans Direct3D 8. Tout simplement parce que la tessellation est devenue un composant obligatoire de Direct3D 11.

Compute shaders

L’une des autres nouveautés de Direct3D 11 est le support des Compute Shaders (CS). Je n’ai pas représenté le compute shader dans le schéma du pipeline ci-dessus tout simplement parce que le CS ne s’intègre pas dans le pipeline graphique.

C’est une nouvelle unité fonctionnelle qui tourne indépendamment des notions de triangles, pixels, sommets. C’est la reconnaissance par Direct3D et Microsoft de l’importance du GPGPU ou programmation à but général sur GPU. Le GPGPU existe depuis quelque temps déjà. Au départ, l’idée d’exploiter les capacités de calcul parallèle des GPU s’est heurtée à la complexité de l’interface. En effet, afin de faire des opérations simples comme un « hello world ! » en GPGPU, il fallait apprendre une toute nouvelle interface de programmation qui le plus souvent introduisait des concepts totalement étrangers à ce que l’on voulait faire. Pourquoi des pixels, sommets, zbuffer quand on veut juste faire tourner une formule mathématique utilisée dans la finance ? Des cartes modernes (Tesla, Firestream) ne gèrent même plus l’affichage et ne s’encombrent pas du bagage de la programmation 3D dans leurs interfaces.

Bien entendu, c’est paradoxal que la reconnaissance du GPGPU passe par l’intégration dans une interface de programmation graphique. Mais c’est juste anecdotique. Le fait est que cela permet une standardisation, condition sine qua none pour que certains développeurs pensent à l’utiliser dans leurs jeux pour des calculs autres que le graphisme (physique, intelligence artificielle, etc.). Il est même possible d’imaginer via l’interaction entre Direct3D et Direct Compute que la partie Compute fasse une partie des calculs de rendu (si on se rend compte par exemple que la notion de sommet, pixel, zbuffer n’est plus indispensable pour certaines parties du rendu), on peut penser au raytracing, deferred shading, rendu par voxel, et j’en passe.

Il est possible que Direct Compute ne remplace pas totalement CUDA (ou autre) pour certaines applications « sérieuses » (Direct compute ne sera pas aussi multiplate-forme par exemple). Par ailleurs, pour l’instant le coût de passage d’un thread compute à un thread 3D n’est pas nul et pourrait nuire aux performances d’une application qui ferait du calcul pur par exemple.

Microsoft a fait la démonstration lors d’une réunion de développeurs de Direct Compute faisant tourner un kernel de post processing (Fast Fourier Transform). Ce module est fonctionnel en pré-alpha sur le matériel actuel (GeForce 8 de NVIDIA utilisé lors de la présentation). Les compute shaders seront, selon toute attente, accessibles sur certaines cartes existantes contrairement à la tessellation qui nécessitera une nouvelle architecture.

Un compute shader se programme de la même manière que tous les autres shaders avec un appel de fonction HLSL. Bien entendu, il y a quelques concessions, avec des instructions intrinsèques pour la synchronisation entre threads (XXXMemoryBarrier), les opérations atomiques sur les variables partagées (InterlockedXXX). Il est également possible de déclarer des ressources « RAW », c’est-à-dire libres de tout formatage particulier (pas de pixel format, de dimension, etc.) qui sont accédées depuis le compute shader par leur offset en nombre d’octets (byte offset). Il peut également accéder facilement aux ressources classiques rendues par les parties 3D (ce qui est tout de même l’un des fondements de cette intégration).

Comme le compute shader utilise les mêmes unités de calcul que la 3D, il n’y a pas d’exécution parallèle entre compute et 3D. Le compute shader et les opérations de tracé classiques doivent s’opérer les unes après les autres de manière sérialisée. Il faut par ailleurs limiter le nombre de va-et-vient entre les deux modes, puisque la transition n’est pas gratuite.

Application du GPGPU à la compression de texture

Multithreading

L’une des autres grosses nouveautés de Direct3D 11 est le rendu multithreadé.

L’idée, c’est qu’une partie non négligeable du temps par image dans un jeu est passé à générer des commandes pour faire tourner la carte graphique. C’est du coût « administratif » qui malheureusement ne peut pas être réduit davantage. Ou du moins pas aussi facilement que l’on voudrait.

Intel estimait récemment que 25 à 40 % du temps CPU par frame était passé dans le runtime et le pilote (pour un jeu moderne) et donc si l’on rajoute par-dessus les cycles additionnels que l’application doit dépenser pour conserver le GPU occupé à plein temps (traversal, système de matériau, gestion de la visibilité, systèmes de particules et généralement toute tâche attachée au graphisme), eh bien on peut probablement arriver à une majorité des cycles CPU passés pour gérer l’affichage. Je parle de coût administratif parce que même si le GPU fait le vrai boulot de rendu, le CPU doit lui soumettre des commandes de tracé en continu et en quantité importante pour les pixels « intéressants » (le coût CPU du pixel intéressant est toujours plus élevé que le coût CPU du pixel du benchmark synthétique).

L’arrivée du CPU multicore ne règle que partiellement le problème. Un exemple de réponse apportée, les pilotes récents vont créer des worker threads (thread « travailleur ») qui vont faire le vrai travail de programmation du matériel par opposition au thread d’acceptation des commandes. Cependant l’interface d’accès à l’API est toujours monothreadée (où doit être sérialisée au point d’avoir une performance monothread). Cette singularité rend difficile la parallélisation effective des tâches de rendu : il est toujours possible de faire le rendu en parallèle avec tout le reste mais si le rendu prend déjà tout le temps disponible et bien ça ne laisse qu’un faible répit. Si on ne fait rien suite à ça, on peut donc imaginer que la puissance des GPU continue d’augmenter exponentiellement, l’API ne progresserait pas en efficacité (coût administratif du pixel intéressant ne décroît pas), et la puissance d’un seul thread CPU ne progresserait pas, remplacée en pratique par une croissance en nombre de cores à la place. Au final on continuerait à sous-utiliser le potentiel de pixels intéressants du GPU.

Comment cela fonctionne ?

L’application va créer un device Direct3D 11 de manière normale puis va appeler la méthode CreateDeferredContext() sur ce device. Pour résumer, il y a deux types de contextes dans D3D 11. Le premier type est le contexte immédiat (immediate context). Il est retourné en sortie de D3D11CreateDevice() :

hr = DXUT_Dynamic_D3D11CreateDevice( pAdapter,
                                     pNewDeviceSettings->d3d11.DriverType,
                                     ( HMODULE )0,
                                     pNewDeviceSettings->d3d11.CreateFlags,
                                     FeatureLevels,
                                     NumFeatureLevels,
                                     D3D11_SDK_VERSION,
                                     &pd3d11Device,
                                     &FeatureLevel,
                                     &pd3dImmediateContext
                                     );

Le deuxième type est le contexte différé (deferred context). C’est ce type là qui est créé par CreateDeferredContext() :

pd3dDevice->CreateDeferredContext( 0 /*Reserved for future use*/,
                                   &pd3dDeferredContext );

L’envoi de commandes graphiques fonctionne de manière identique sur chaque contexte. La seule différence c’est que les commandes du contexte différé ne sont pas envoyées vers le pilote ni exécutées par le GPU directement.

Ces commandes sont mises à la place dans une liste de commandes (command list) qui est stockée de manière opaque (pour permettre plusieurs implémentations différentes, voir plus bas). Cette liste de commandes est récupérée lorsque l’on a fini le rendu sur le contexte différé :

pd3dDeferredContext->FinishCommandList( FALSE, &pd3dCommandList);

Puis le pointeur récupéré de la liste de commandes est envoyé sur le contexte immédiat :

pd3dImmediateContext->ExecuteCommandList( pd3dCommandList, FALSE );

Avertissement : chaque contexte a son propre jeu d’états, et donc le changement d’un render state dans un des contextes n’influe pas sur le render state d’un autre état et l’état des contextes est remis à zéro entre chaque exécution/finalisation de liste de commandes. Si vous faites :

deferredContext1->RSSetState(state 1)
deferredContext1->Draw()
deferredContext1->FinishCommandList(A)
deferredContext2->Draw()
deferredContext2->FinishCommandList(B)
immediateContext->RSSetState(state 2)
immediateContext->ExecuteCommandList(A) <- Ici Draw() est fait avec state 1
immediateContext->ExecuteCommandList(B) <- Ici Draw() est fait avec state par défaut
immediateContext->Draw()                <- ici Draw() est fait avec l'état par défaut
deferredContext1->Draw()
deferredContext1->FinishCommandList(C)
immediateContext->ExecuteCommandList(C) <- state par défaut

Les commandes sont bien sérialisées quand elles sont soumises au GPU mais chaque contexte est considéré comme indépendant des autres. L’inconvénient c’est que, par contre, le passage d’un contexte différé à un autre va forcer le renvoi des états qui diffèrent, voire une réinitialisation complète, ce qui peut poser des problèmes de performance si l’opération de tracé qui a été différée n’est pas assez importante pour cacher ce coût. Les contextes différés doivent donc être conséquents pour qu’il n’y ait pas de perte de performance (avant même de parler de gain de performance).

Exécution d’un contexte de rendu différé

Il y a tout de même des moyens d’hériter certaines propriétés, en effet même si les render states sont remis à zéro entre les exécutions/finalisations, ce n’est pas le cas des ressources Direct3D. Même si ne sont pas des render states à proprement parler, ils peuvent influencer l’exécution des opérations de tracé.

Comment peut-on donc gagner en performance avec ce mécanisme ?

Grâce à deux algorithmes. Le premier peut profiter à toute plate-forme, pas seulement celles qui sont fortement multithreadées. Il s’agit de constituer des listes de commandes qui seront tracées souvent mais ne changent pas souvent. Le coût de construction de la liste est donc factorisé, ne reste que le coût de l’exécution. Le deuxième bénéficie aux plates-formes fortement multithreadées, il s’agit de faire tourner des sous-parties de rendu de scène sur des threads différents. Avec un bon découpage il est possible d’occuper tous les cores avec des assemblages de scène et de réduire le thread principal à exécuter les listes de commandes.

Contrairement à la tessellation et aux compute shaders, c’est une fonctionnalité entièrement logicielle. C’est-à-dire qu’elle pourra fonctionner à la fois sur une nouvelle carte graphique Direct3D 11 et ses pilotes niveau 11_0, qu’une vieille carte Direct3D 9 et ses pilotes niveau 9_1.

Cependant chaque niveau de pilote va apporter un gain de performance différent. Le pilote de niveau 9 par exemple reste fortement sérialisé (avec éventuellement l’optimisation du worker thread qu’on a évoqué ci-dessus). La raison est que l’interface du pilote (DDI) a été pensée dans un univers monocore et que chambouler cette interface pour du matériel qui n’est plus en vente n’est pas très intéressant pour les vendeurs de cartes. Le support des contextes différés est donc émulé par le logiciel. Mais il peut tout de même y avoir un intérêt ne serait-ce que parce que l’application peut traiter sa partie de code comme des unités travaillant en parallèle ou minimiser le nombre d’appels à l’API. Le runtime aussi peut faire tourner une partie de ses calculs en parallèle et ne sérialiser qu’à la frontière du pilote.

Un nouveau type de pilote va faire son apparition pour apporter le maximum de gain à ces techniques, c’est le pilote free-threaded (fil d’exécution libre). La particularité de ce pilote c’est qu’il peut être appelé de n’importe quel thread en simultané (mais toujours sérialisé du point de vue du deferred context bien entendu) et qu’il ne doit pas bloquer l’exécution d’un thread du contexte 1 pour l’exécution d’un thread du contexte 2 (pour maximiser le parallélisme bien sûr). De plus, un pilote qui aurait le concept de contexte différé en vue pourrait assembler les listes de commandes dans un format natif, elles n’auraient alors plus qu’à être copiées en place finale lors de l’exécution. Ce pilote là bénéficiera grandement de la technique du préassemblage et exécution multiple, le coût total du préassemblage est factorisé sur les exécutions dont le coût CPU est réduit (théoriquement) à la copie. Bien entendu, c’est la théorie, reste à voir si les implémentations des différents constructeurs peuvent atteindre leur plein potentiel.

Divers

Direct3D 11 offrira, en plus de toutes ces fonctionnalités, quelques mises à jour plus ou moins attendues.

Par exemple, le linker de shaders dynamique fera son apparition. Cela est censé résoudre le problème d’explosion combinatoire du système de matériel d’un jeu moderne. En effet, un matériel est souvent décrit par une flopée de bouts de codes qui peuvent être mis bout à bout de manière conditionnelle. Par exemple un objet diffus de base, peut devenir mouillé et récupérer un reflet spéculaire, puis peut être éclairé par un nombre de lumières variable, de différents types, avec des ombres précalculées ou dynamiques, avec du brouillard ou non, volumétrique ou global, et le tout modifié par un effet de vision XRay activable et désactivable à volonté par le joueur.

De nombreux éditeurs de jeux proposent par exemple aux artistes d’assembler des shaders avec des blocs de type Lego ce qui est sans doute pratique d’un point de vue artistique mais terriblement inefficace quand on pense à la somme de shaders différents générés qu’il faut ensuite envoyer à la carte graphique, convertir de HLSL en byte code du shader model 4, compiler pour le code natif de la carte, optimiser, etc. Une option envisageable était d’utiliser un über shader ou shader où tout le code possible est présent et simplement « activé ou non » par des constantes. Problème : c’est que le branchement n’est pas forcément gratuit, et que l’utilisation des ressources (textures, registres, inputs) doit s’accommoder du pire cas. De plus, le pilote pourrait très bien décider que l’über shader pourrait être mieux optimisé et recompilé au cas par cas. La solution du linker dynamique est donc une solution intermédiaire où les bouts de codes sont compilés indépendamment puis assemblés (en supposant que l’assemblage puisse être rapide) lors de l’exécution. Solution intermédiaire qui est sans doute meilleure que l’über shader ou la recompilation à tout-va, mais va-t-elle satisfaire les amateurs de performance ?

Assemblage de shaders, copyright Epic games

À cela il faut rajouter de nouvelles fonctionnalités mineures, comme le support de nouvelles textures compressées et optimisées pour les formats « HDR » (higher dynamic range). Des ajouts au support de Gather4 (lecture de quatre samples adjacents sous Direct3D 10.1 qui ne doivent plus forcément être adjacents dans Direct3D 11), des flux de sortie (stream output) adressables, la double précision, etc, etc, etc. Avec Direct3D 11, Microsoft a aussi annoncé un nouveau renderer logiciel appelé WARP Ten (en référence à Star Trek ?). Contrairement à Refrast (qui continue d’exister et qui reste la référence), Warp Ten peut être déployé en environnement de production et est optimisé pour la vitesse. L’objectif annoncé est d’offrir un fallback pour que plus d’applications utilisent Direct3D 10 pour leur rendu de base. Ce sera par exemple le cas du nouveau bureau de Windows Seven et du module Direct2D (un GDI/GDI+ accéléré).

Conclusion

On a donc vu que Direct3D 11 est le fruit d’un long historique de développement des API graphiques par Microsoft. Et étrangement il reprend à son compte quelques choix de ses ancêtres que l’on croyait pourtant abandonnés (rétrocompatibilité, émulation logicielle).

Même si le rythme de sortie des API de Microsoft semble avoir largement ralenti, il y a encore des critiques qui l’estiment trop rapide. Pourtant les enjeux sont importants, les ajouts techniques sont indéniables et la nouvelle mouture s’offre même le luxe d’apporter de nouvelles fonctionnalités comme le device multithreadé et les compute shaders à des cartes existantes. Bref c’est une annonce excitante dans le monde de la 3D temps réel. On peut l’apprécier pour cela, tout en répétant qu’il ne faudra se précipiter dessus qu’après analyse préalable de vos besoins particuliers. Mais ce serait enfoncer des portes ouvertes.

À lire aussi

Direct 3D 10 du changement en perspective

Courbes et surfaces de Bézier

Tessellation of subdivision surfaces

Présentation Compute Shaders par Chas Boyd

Présentation Direct3D 11 par Chas Boyd

Direct3D 11 Technology Preview - DirectX SDK Novembre 2008

“C’est pour cette année” annonce-t-on chez Microsoft. “Je n’ai pas encore commencé à utiliser les shaders, DirectX 10 n’est même pas encore sur ma to-do list : pourquoi sortent-ils encore une nouvelle version ?”, entend-on chez les autres programmeurs. Malheureusement - ou heureusement selon les points de vue - le monde du jeu, des cartes graphiques et des APIs graphiques évoluent constamment. Dans cet article on va faire le point sur l’évolution de l’interface DirectX depuis ses débuts jusqu’à la version 9.

Un peu d’histoire

DirectX 11, c’est le fruit d’une longue histoire. C’est l’histoire du graphisme sur PC. Il n’y a pas si longtemps que ça, on classait les puces graphiques en fonction du nombre de couleurs et de pixels, voire de caractères de texte, que l’on pouvait afficher. La partie qui nous intéresse à savoir le tracé était le plus souvent généré par le CPU ou processeur central généraliste. Il y avait bien les stations de travail pour les applications graphiques de Silicon Graphics, HP et Evans et Sutherland mais ça ne touchait pas le monde du PC que vous pouviez acheter au supermarché du coin. Dans ce monde les « API graphiques » étaient un grand mot, on avait besoin d’instructions pour changer le mode graphique et pour allumer/éteindre un pixel à l’écran. Cela suffisait pour afficher des graphismes simples à la Castle Wolfenstein 3D, mais qui en contrepartie avait besoin d’un CPU assez puissant (mais rien en comparaison de ce que l’on a maintenant). Pendant ce temps, les interfaces graphiques ont commencé à remplacer les vieilles interfaces textuelles et la multiplication des fenêtres et des applications graphiques gourmandes à la CorelDRAW/Photoshop ont créé un nouveau marché : celui des accélérateurs d’interface graphiques (ou GUI accelerator). Capables d’accéder directement à la mémoire sans faire appel au CPU (DMA ou direct memory access), de remplir des rectangles, polygones, tracer des lignes, voire de remplir des zones de l’écran avec des textures (en général une simple copie parfois avec redimensionnement). Ces capacités étaient les bienvenues dans le monde du PC qui devenait de plus en plus graphique mais il y avait un grand besoin de standardisation.

Standardisation des pilotes

Quand quelqu’un écrit une application pour PC, s’il a une puce graphique spécialisée qui accélère certains calculs comme le tracé de polygones texturés, il pouvait avoir le choix d’utiliser les registres de la puce en question qui étaient documentés par le constructeur de la puce ou de faire appel à une interface de programmation standardisée pour laquelle le constructeur a fourni un logiciel pilote (aussi appelé driver comme en anglais). Ce logiciel pilote est donc le plus souvent chargé de faire le lien entre l’interface standardisée et les registres spécifiques du matériel. Notez que cette distinction n’est pas toujours aussi claire. Dans les premiers PC, le matériel était programmé avec les registres spécifiques. Et donc lorsque des clones de ces PCs apparaissaient, ils se devaient d’émuler ces registres spécifiques même s’ils utilisaient une puce d’un constructeur différent. L’interface spécifique devenait donc le standard de facto. Il y a plusieurs niveaux de compatibilité : “pin compatible” ce qui permet de substituer physiquement les puces, ou de juste substituer les registres, juste les codes d’échappement ou juste créer une interception de plus haut niveau, comme les glide wrappers dans l’histoire plus récente. Cette situation peut arriver encore de temps à autre aujourd’hui mais à plus petite échelle.

Le monde du jeu vidéo cependant restait bloqué sur les interfaces bas niveau et s’il y avait de la standardisation (VESA) elle n’accélérait que le strict minimum (changement de mode d’affichage, accès en écriture direct à la mémoire d’affichage, double buffering). Ce qui fait que bien souvent, au début, les jeux vidéo continuaient à tourner sous l’interface textuelle de MS-DOS tandis que les applications “sérieuses” migraient sous Windows 3.1 avec l’accélération GDI. GDI était considérée comme trop lente pour ce que les développeurs de jeu voulaient faire et le fait de tourner sous Windows détournait une partie des ressources nécessaires aux jeux exigeants de l’époque.

WinG - premier standard Windows pour les jeux

La première tentative de faire migrer les développeurs de jeux sous Windows est venue avec WinG (prononcez “ouine-dji”). Là encore la seule “accélération” proposée par WinG était en fait la suppression des couches intermédiaires qui empêchaient les développeurs de travailler directement sur la mémoire d’affichage. C’est-à-dire essayer de rendre une application Windows aussi rapide qu’elle pouvait l’être sous DOS. WinG est ensuite devenu DirectDraw, inclus dans DirectX 1 (aussi appelé GameSDK). Avec DirectX 1, Windows 95 était devenue une plateforme de jeu à part entière sans raison de conserver MS-DOS comme une alternative viable.

La révolution des accélérateurs

Pendant ce temps-là, une autre révolution était en train d’arriver. Matrox, 3Dlabs, 3dfx, NVIDIA, PowerVR, Rendition lançaient quasi simultanément leurs accélérateurs 3D pour PC. Certains “accélérateurs” de cette époque étaient de simples évolutions des accélérateurs de GUI, ces derniers avaient la possibilité d’afficher des polygones texturés, les accélérateurs 3D étendaient cette capacité en ajoutant la possibilité de faire de l’interpolation perspective (interpolation avec coordonnée homogène W), parfois du filtrage (bilinéaire) et des opérations de blending (mélange de couleurs). Certains ne faisaient que ça, laissant le lourd héritage de la compatibilité aux acteurs établis. Chacune de ces entreprises avaient toutes en commun le but de devenir le seul acteur viable. Ce qui pourrait paraître comique aujourd’hui faisait sens à l’époque, chaque puce graphique avait sa propre interface de programmation. Les développeurs de jeu devaient donc choisir leur allégiance ou faire du code facilement adaptable. Ceux qui ont choisi la deuxième voie comme Criterion Studios (RenderWare) ou RenderMorphics (Reality Labs) ont eu un destin un peu particulier on y reviendra.

La situation s’est éclaircie rapidement, les développeurs de jeu ont plébiscité l’offre de 3dfx avec son interface propriétaire Glide. De plus en plus de jeux de l’époque ne proposaient que deux modes : le rendu logiciel (sur le CPU) ou matériel avec Glide.

Arrivée de Direct3D

Microsoft de son côté se retrouvait dans la même situation d’avant DirectDraw puisque tous les jeux migraient vers la 3D que DirectDraw n’accélérait pas. Plutôt que de développer sa propre interface 3D, certaines personnes poussaient Microsoft à adopter OpenGL. OpenGL tournait déjà sous Windows, il y avait une version qui tournait avec un rendu logiciel et des ports miniGL (pilote OpenGL minimal pour accélérateur graphique) qui faisaient tourner GlQuake par exemple. Mais Microsoft ne contrôlait pas OpenGL (initialement créé par Silicon Graphics sa destinée était contrôlée par l’ARB un consortium d’entreprises diverses et variées) : OpenGL ne bougeait pas assez vite (décision par comité), était un investissement lourd à supporter pour un constructeur spécialisé dans les pilotes bas niveau (les full OpenGL ICD n’arriveront pas avant quelques années et avec pas mal de “ratés”), et selon certains ne pouvait pas supporter le degré d’accélération nécessaires par les jeux de l’époque (rappelons que le rendu software était encore important). Mais plutôt que de repartir de zéro, Microsoft avait racheté Rendermorphics, une entreprise qui développait des jeux et un moteur 3D. Reality labs de Rendermorphics était un moteur fonctionnel avec scene graph haut niveau, et une interface bas niveau qui permettait de faire tourner les jeux sur plusieurs types de matériels (une couche d’abstraction matériel ou HAL). Peut-être que le focus en achetant RenderMorphics s’est trop portée vers l’accélération du rendu via le CPU, mais c’est sans doute plus facile à dire rétrospectivement que dans le feu de l’action de l’époque.

Monster truck madness est l’un des premiers jeux a exploiter Direct3D

Disparition des interfaces propriétaires

3dfx était encore trop occupé à promouvoir Glide, mais Microsoft pouvait compter sur le support fort d’Intel (avec i740), ATI (avec Rage 3D) et NVIDIA (avec Riva 128). Ces cartes avaient comme particularité de ne tourner qu’avec les API standards (Direct3D et OpenGL via miniGL au début puis Full OpenGL ICD par la suite), cela annonçait la fin des API propriétaires (pour la 3D). De plus au même moment, la notion de carte exclusivement 2D disparaissait, il n’y avait plus que des cartes accélératrices 3D qui faisaient aussi de la 2D. Du même coup, tous les vendeurs qui ne faisaient que de la 2D ont été absorbés ou ont disparu.

Évolution à marche forcée

Les révisions fréquentes de DirectX étaient nécessaires parce que les constructeurs annonçaient régulièrement le support de nouvelles fonctionnalités que l’ancienne version ne supportait pas. DirectX 3 était la première version à proposer Direct3D (Direct3D 1 = Direct3D 3 d’une certaine façon), basée entièrement sur Reality Labs avec le scene graph haut niveau et les execute buffer bas niveau. Direct3D 3 n’a pas plu à grand monde à l’exception de certains développeurs anglais. Microsoft a sauté DirectX 4 pour des problèmes de mauvais planning et a livré DirectX 5 avec une version améliorée de Direct3D. Les execute buffers étaient remplacés par des appels de fonctions explicites comme Clear(), DrawPrimitive(), SetRenderState() ce qui a fait taire les plus critiques de l’époque. Oui, cela semble incroyable aujourd’hui mais en pratique il s’agissait juste d’un réhabillage, les execute buffers étant toujours présents en coulisse mais cachés au programmeur.

Direct3D 6 apportait le multitexturing (possibilité de mixer deux textures en une seule passe, par exemple mélanger une lightmap avec une texture diffuse comme dans Quake 2). Direct3D 7 offrait pour la première fois le support de la transformation et de l’éclairage par le hardware graphique (quelque chose qui était déjà possible sous OpenGL mais en pratique pas encore supporté par les cartes grand public), les textures cubes, les textures “managed”, et un bond dans la complexité des texture stage states. Puis enfin est arrivée la programmabilité dans les texture stage states et dans la transformation et l’éclairage avec Direct3D 8 et ses pixel / vertex shaders.

Premier test des pixel shader dans 3dmark 2001

Direct3D 9 - enfin un standard stable

Direct3D 9 a enfoncé le clou en étendant la programmabilité, en proposant le rendu vers des textures à précision flottantes (16 bits et 32 bits flottants par canal) et en apportant une grande amélioration de l’interface de programmation elle-même. Chaque version de Direct3D était rétro-compatible avec la précédente. Cela veut dire plusieurs choses, 1 - il était possible de créer le même device identique sur toute carte graphique avec un support Direct3D 7 minimal. 2 - les applications écrites pour Direct3D 1-2-3-5-6-7-8 devaient pouvoir tourner sur les cartes graphiques qui avaient un driver compatible Direct3D9 (de même une application D3D 1 tournait sur 5, D3D 5 tournait sur 7 etc.). Cela a pas mal limité certains choix d’architecture de l’API elle-même et d’une certaines façon les drivers et le runtime ont pâti de cette nécessité de supporter plusieurs degrés de features avec la même interface. Mais c’était indispensable pour maintenir le taux de pénétration maximale de Direct3D dans le domaine du jeu - Direct3D étant entré en concurrence avec OpenGL dès ses débuts, concurrence qui ne s’est terminée qu’à la sortie de Direct3D 9.

Un an s’était écoulé entre D3D3 (1996) et D3D5 (1997), un an entre D3D5 et D3D6 (1998), encore un an entre 6 et 7(1999), un peu plus d’un an entre 7 et 8(2001) et un peu plus d’un an entre D3D8 et D3D9 (2002/2003). Comme on peut le voir le rythme était très rapide. Mais ce n’était pas forcément un problème parce que les changements étaient très incrémentaux. Par ailleurs au tout début de la 3D le développement de jeu était rapide et parfois le code graphique était réécrit entre les jeux parce que les paradigmes changeaient rapidement (2.5D à 3D software, 3D software à accéléré 3D, accéléré 3D à shaders).

Stagnation

Puis il y a eu un grand vide. Direct3D 9 était-elle la seule interface de programmation dont vous auriez jamais besoin ? Probablement pas, mais son successeur n’est pas sorti avant 2007 soit trois-quatre ans après son introduction ce qui aurait pu sembler une éternité dans le monde du développement de jeu et des cartes graphiques quelques années auparavant. Mais il y avait des signes qu’il n’y aurait pas besoin de plus pendant quelques temps. Le nombre de concurrents dans le secteur de la 3D grand public est dramatiquement tombé à trois (plus deux-trois qui ramassent les miettes). La rapidité d’innovation devenait plus difficile à maintenir avec des features de plus en plus complexes (la lecture de deux textures en simultané justifiait la sortie d’une nouvelle carte et d’une nouvelle API quelques années auparavant), des puces graphiques de plus en plus grosses (la validation elle-même prend des mois), des gammes qui s’étendent (3dfx avait un seul produit la voodoo1, remplacé plus tard par la voodoo2 dans la même gamme de prix). Et puis un facteur important était que pour la première fois, Microsoft avait tenu à créer une API plus durable en faisant de Direct3D9 la première version de Direct3D qu’aucun hardware ne pouvait accélérer complètement à sa sortie - les shaders 3.0 ont commencé à être supporté par les Geforce 6800 en avril 2004, les textures flottantes avec multisampling par la Radeon X1800 en octobre 2005.

Cela a des avantages et des inconvénients. Dans les inconvénients, d’un point de vue marketing, pendant trois ans, chaque mise à jour de cartes graphiques se distinguait de la version précédente grâce à un artifice marketing (comme Direct3D9 “plus”). Et les trous dans l’API - malgré son excellent design de départ - sont devenus de plus en plus flagrants au cours des années.

Mais dans les avantages, il y a la stabilité que le non-changement d’API a apportée. Bien entendu, il y a des développeurs qui ont résisté et qui ont continué à distribuer des jeux programmés avec Direct3D8 dans les deux ans qui ont suivi la sortie de Direct3D 9. En pratique, il est certain que cette stabilité a contribué à la force de Direct3D, notamment en accroissant son impact sur les développeurs aux dépens d’OpenGL. Encore aujourd’hui, dans des temps incertains, Direct3D9 - qui ressemble de plus en plus à un bateau qui fuit de partout six ans après son introduction - reste l’API de référence pour les développeurs PC, sur plate-forme Windows bien entendu.

Crysis summum du rendu Direct3D 9

Le futur

Allez voir les articles suivant pour vous faire une idée de l’après DirectX 9.

Direct 3D 10 du changement en perspective

Un avant goût de DirectX 11

En fait rien de tout cela il s’agissait d’un vulgaire bug. Plus d’info après le saut.

Certaines personnes ont mis la main sur le code qui contrôle l’horloge temps réel du Zune et cela a été confirmé indépendamment par Microsoft. 2008 est la première année bissextile (leap year in English) que rencontrent les Zune de première génération. Tout devrait être correctement géré, le code en question faisant appel à une fonction pour vérifier que l’année était bien bissextile et à ne sauter l’année que si le nombre de jours écoulés étaient supérieurs à 366. Seul problème, le code n’était pas complet.

while (days > 365)
{
  if (IsLeapYear(year))
  {
    if (days > 366)
    {
      days -= 366;
      year += 1;
    }
  }
  else
  {
    days -= 365;
    year += 1;
  }
}

Si vous exécutez le code ci dessus et que la valeur de la variable days == 366 avec IsLeapYear(year) qui retourne TRUE, alors la condition de la boucle while est vraie, la première condition sur l’année bissextile est vraie, la deuxième condition sur le nombre de jours est fausse.. Et on reboucle puisqu’aucune condition sur les variables n’a changé.

Le gel des Zune est donc dû à une boucle infini dans ce code.

La solution ? Éteindre le Zune jusqu’à ce que la batterie soit complètement vide (pour faire un hard reset ?) et ne rebooter que le 1er janvier 2009 pour être sûr que la condition menant au bug ne soit plus exécutée. Et attendre patiemment jusqu’à 2012 (il y aura probablement une mise à jour du logiciel embarqué d’ici là).

Un autre bout intéressant dans ce code donne l’intervalle des dates valides et il semblerait que seule la plage 1980-2080 soit supportée, toute date qui n’est pas dans cet intervalle est considérée comme invalide. Là on est plus dans le cadre de l’obsolescence planifiée.

PS : Bonne année 2009 !

Qu’est-ce que WARP ?

WARP est un nouveau software rasterizer (moteur de rendu par rasterisation tournant sur le CPU) capable de rendre les triangles et les shaders envoyés par les applications Direct3D 10 sans besoin de passer par la carte graphique (à part pour mettre le résultat à l’écran).

Un peu d’histoire

Ceci dit ce n’est pas le premier software rasterizer que Microsoft met à la disposition du public. Ceux qui traînent leurs guêtres dans la 3D depuis perpète se souviennent du moteur OpenGL software qui faisait tourner les fonds d’écran Windows (avant que Microsoft ne les recode à l’identique pour tourner avec Direct3D). Ou du rasterizer software appelé RAMP qui faisait tourner les toutes premières applications Direct3D (Terminal Velocity par exemple) et qui était parfois plus rapide que les tout premiers “accélérateurs”. Ces moteurs de rendu n’ont pas été remis à jour depuis et sont tombés dans l’oubli : l’accélération OpenGL complète est devenu un must des cartes graphiques récentes et Microsoft ne livre plus du tout sa version d’OpenGL, RAMP n’a pas évolué au delà du mode 8 bits avec couleurs palettisées.

Plus récemment encore, Microsoft fournissait avec chaque nouveau SDK le Reference rasterizer (aussi appelé Refrast pour les intimes). La limitation du refrast est que c’est uniquement un outil de validation, qu’il est particulièrement lent (pas de rendu interactif) et que Microsoft n’autorise personne à livrer le reference rasterizer en dehors du DirectX SDK. C’est à dire seuls les développeurs d’application y ont accès.

Quels sont donc les objectifs de Microsoft avec ce retour au rendu software ?

Objectifs

Ce qu’il faut souligner c’est que Microsoft ne désire pas du tout concurrencer les vraies cartes graphiques avec ce moteur de rendu software. On reviendra plus loin sur les performances mais elles ne viendront même pas remplacer les cartes les plus bas de gamme (de NVIDIA ou ATI).

Un gamer aura donc tout intérêt à continuer à acheter une carte graphique spécialisée, tout simplement parce qu’un GPU reste largement plus efficace qu’un CPU pour ce genre de tâche.

Pareil pour les développeurs de jeux AAA (Crysis, Half Life, Spore etc), il n’est pas question de revenir au rendu software sauf à devoir ramener la qualité du rendu vers le bas, baisser les résolutions très fortement, limiter le nombre des objets affichables, et ne plus écrire que des shaders très simples. Bref un retour de quelques années en arrière.

Non l’objectif de Microsoft n’est pas ces deux marchés qui ont déjà compris l’intérêt d’avoir acheté une carte graphique milieu ou bas de gamme. L’objectif c’est le marché des applications qui n’ont pas besoin d’autant de puissance mais pourraient tout de même bénéficier d’une interface unifiée pour à la fois profiter de l’accélération de certains hardware tout en tournant correctement sur le PC qui n’a même pas de driver graphique installé ou qui ne peut pas utiliser les capacités du hardware graphique.

En clair ?

Voici quelques exemples d’utilisation :

Premier exemple :

Un développeur de jeux casual doit tourner sur une machine qui n’a pas de driver graphique installé. Dans la situation pré-WARP, il devait faire appel à des appels GDI classiques pour tout le jeu ou faire deux bases de code, une utilisant GDI et l’autre utilisant DirectDraw ou Direct3D. En plus de multiplier les bases de code, GDI manque de certaines fonctions super faciles à implémenter avec Direct3D (semi-transparence, shaders etc). WARP lui permet d’écrire le même code qui tourne partout, avec éventuellement des effets à activer ou désactiver pour tourner sur les machines les moins puissantes. Mais même sur la machine la plus lente il est garanti que son jeu s’affichera correctement même si lentement.

Deuxième exemple :

Dans certains environnement virtualisés (VMWare, virtual PC ou services en tâche de fond), les accès au hardware graphique ne sont pas disponibles ou sont très lacunaires ou avec de gros bugs. Une application qui doit tourner partout ne peut donc pas utiliser Direct3D pré-warp. Écrire avec WARP en tête lui permet d’exploiter le hardware graphique lorsqu’il est présent et d’utiliser le même moteur de rendu (avec des effets en moins si nécessaires) dans le cas où il est inaccessible.

Troisième exemple :

Un joueur a une puce graphique intégrée à la carte mère de marque Intel. Même si la puce prétend être compatible Direct3D10, en réalité elle est lente et pleine de bugs ce qui fait que le développeur va se prendre la tête à faire tourner son code correctement sur cette carte pour une petite fraction des utilisateurs qui pourraient rencontrer ces bugs. Plutôt que de perdre son temps sur cette activité hautement économique, il peut cibler le software renderer WARP qui va s’exécuter partout pareillement. Et dans certains cas plus rapidement que la cible intégrée d’Intel (on y reviendra).

Quatrième exemple :

Une application utilise le hardware graphique pour accélerer certains traitements (décodage/encodage vidéo, folding de protéines, etc). Avant il fallait cibler une certaine classe de hardware avec l’API 3D et l’autre classe avec une version spéciale de l’algorithme tournant sur le CPU. En ciblant WARP, une seule base de code peut à la fois tirer partie du rendu accéléré par la carte 3D ou une accélération par le dual/quad/octo core lorsque la carte graphique ciblée n’est pas dans le système (un algo demande le support des entiers par exemple qui n’est accessible qu’aux cartes d3d10 et ultérieures).

NVIDIA propose déjà en partie cela avec CUDA qui a une implémentation hardware tournant sur ses cartes et une implémentation software optimisée. Cela veut dire que quelqu’un peut écrire du code CUDA et avoir un gain immédiat de performance juste grâce au runtime optimisé pour le multicore-multithreaded, même sans carte NVIDIA dans le système.

Cinquième exemple :

Tout comme avec le refrast, le rendu software permet de prototyper des applications utilisant une nouvelle API 3D avant que le hardware qui supporte les dernières fonctions n’arrive. Par exemple, de nombreux développeurs ont commencé à réfléchir à de nouveaux effets 3D possibles avec Direct3D 10 en utilisant le Refrast qui était disponible de nombreux mois avant que le hardware et les drivers bétas ne soient disponibles. Le problème du refrast était qu’il était très lent. Ce nouveau software rasterizer WARP au contraire est optimisé pour la vitesse d’exécution (tout est relatif voir plus bas). Même si ce n’est pas aussi idéal que de passer par le vrai hardware, en son absence c’est une bénédiction.

Performance

Microsoft a lancé quelques benchmarks pour donner une idée de la performance de la bête. Sachant qu’il pourra être amélioré à l’avenir et que son objectif premier n’est pas le jeu vidéo.

En 800×600, settings au minimum, le mode benchmark de Crysis tourne à 2,83 fps sur un Core 2 Duo à 2.6Ghz. Le mieux qu’il fasse c’est 7,36 fps sur un Core i7 à 3Ghz (4 cores * 2 thread natifs).

Dans les mêmes conditions, une geforce 8800 GTS fait 84 fps.

On le voit l’objectif n’est clairement pas de concurrencer la carte même bas de gamme (la 8400GS fait 34 fps).

Le seul cas où la situation n’est pas aussi claire c’est sur l’Intel graphics Dx10 qui tourne à 5,17 fps dans la même situation. Le gain de faire tourner sur Intel graphics n’est pas franchement aussi intéressant, sans compter le temps supplémentaire de développement pour contourner les bugs etc (cf mon troisième exemple plus haut).

Support

WARP est un software rasterizer disponible uniquement sous Vista. Il peut-être distribué avec n’importe quelle application et n’a besoin d’aucun support hardware (il peut tourner sur le driver VGA de base). Il n’y a aucun plan de le distribuer sous XP par contre, ce qui va sans doute limiter son adoption dans un premier temps (les avantages cités ne se réaliseront pas s’il faut une base de code spéciale pour XP). Mais bon dans les prochaines années XP va devenir peu à peu obsolète pour les nouvelles applications.

WARP à l’heure actuelle supporte les capacités des cartes D3D9, D3D10 et D3D10.1 et sera mis à jour pour supporter D3D11 lorsque celui-ci sortira (ou un peu avant pour permettre aux développeurs de s’y mettre). WARP est totalement “compliant” c’est à dire que si c’était un hardware graphique, ses drivers seraient certifiés WHQL (windows harware quality labs, seuls les drivers certifiés WHQL sont signés par Microsoft et peuvent être installés sous Windows Vista 64 bit edition par exemple). Les specs de D3D10 et D3D11 étant beaucoup plus restrictives que les anciennes specs de D3D9, il y aura très peu de différence de rendu entre les différentes implémentations (ATI/NVIDIA/Software).

Futur

L’adoption de WARP est difficile à prévoir, savoir ce que les gens en feront ou si Microsoft continuera à le développer activement etc. Je pense qu’elle répond en partie à une logique de Microsoft de faire de moins en moins confiance aux fournisseurs de hardware (suppression de la couche audio accélérée de Vista pour offrir un mixer audio tournant à l’identique partout). Mais pas uniquement et de toute façon à plus ou moins long terme Microsoft ne peut pas se passer du hardware.

Je suis sûr que certains feront le rapprochement avec Larrabee d’Intel, mais ça n’a probablement aucun rapport. Larrabee est une solution hardware qui va concurrencer les offres haut de gamme de dans un ou deux ans. Même si Larrabee est présentée comme offrant la possibilité de revenir à une approche plus “software” du rendu ce n’est pas du tout dans la même optique non plus. Le soft à écrire pour Larrabee (avec la théorie selon laquelle les dévs de jeux retourneront dans le cambouis pour écrire leur rasterizer/raytracer) demande une nouvelle base de code alors que WARP abstrait la base de code en proposant une approche “fixed function”. En gros Larrabee cible la partie du public que WARP ne cible pas.

Est-ce que le rendu software concurrencera les cartes graphiques haut de gamme lorsque les CPUs auront 16/32/64 cores en standard ? Peut-être.. si les cartes graphiques haut de gamme de leur côté n’évoluent pas ce qui est difficile à imaginer. La différence d’avancée montrée entre le core i7 et la geforce 8800gts, ci dessus, a encore augmenté avec la sortie de la gtx280 et augmentera probablement encore plus avec les prochaines cartes D3d11. Est-ce que cette distinction sera encore pertinente dans 2 ans ? 5 ans ? 10 ans ? Qui vivra verra, je ne sors pas ma boule de cristal et je vous laisse faire vos prédictions.

Line art

Les premiers écrans n’avaient pas de “frame buffer” (mémoire prohibitive) et donc les graphismes étaient plus proches de ce que pouvaient faire les “oscilloscopes”. Un rendu de lignes et courbes entièrement analogique.

Tennis for two

On imagine souvent que les premiers jeux vidéos avaient un look carré (“blocky”) parce qu’on a Pong en mémoire, mais ce n’était pas le cas, les premiers affichages pilotés par ordinateur avaient la finesse des écrans d’oscilloscopes et leurs limitations aussi, permettant ce genre de délire (Tennis for two) :

Stockage

La représentation choisie était vectorielle (bien avant l’arrivée des cartes 3D) tout simplement parce qu’il était plus simple de dire au rayon d’électron d’aller de A à B. Certains écrans étaient persistants (quand la liaison écran/terminal à l’ordinateur était très limitée) et la seule façon d’effacer une partie de l’écran était par une commande “clear” qui effaçait la totalité de l’image (quoiqu’il était parfois possible d’afficher un curseur mobile en sus, le plus souvent controlé par crayon optique directement sur l’écran).

Le making off des graphismes de synthèse de Star wars (le premier)

Star wars était l’un des pionniers pour l’utilisation de la 3D dans une des séquences du film.

Pixar’s debut

Pixar avait commencé par essayer de vendre ses logiciels avant de faire des films, Typestry était l’un de leur succès d’estime au début. Puis changement stratégique, Pixar allait faire des films, accord avec Disney, suppression de leur branche software à part PRrenderman leur moteur de rendu. Clin d’oeil de cette époque.

Pourquoi une théière ?

Pourquoi pas ? Les premières images sur ordi avait un côté très abstrait (sphères, cubes, dodécaèdres) et donc Martin Newell (de University of Utah) a eu l’idée de modéliser une théière qui traînait chez lui sous formes de splines (des lignes et surfaces courbes). C’est évidemment une approximation de la théière originale, des versions plus jolies et remises à jour existent maintenant.

Silion graphics

Silicon graphics était l’un des premiers intervenant proposant des solutions graphiques complètes, certes ce n’était pas le seul (Evans et Sutherland etc.) mais ils proposaient une solution complète et relativement abordable qui allait être la référence pour les années à venir.

Pour rire, une image de leur CPU (solution IRIS 3000) :

Le GPU et le frame buffer de la bête étaient du même tonneau.

Talisman

Talisman était une tentative par Microsoft de révolutionner le rendu 3D avec beaucoup d’idées inspirées du traitement 2D pour limiter l’impact du rendu sur la bande passante et le fill rate. Les limites théoriques imaginés par Microsoft ne sont jamais arrivé, aucun constructeur de carte graphique ne s’intéressa à la technique et l’initiative Talisman ne laissera que quelques papiers de recherche, un prototype logiciel et un court métrage d’animation montré à l’electronic theater du Siggraph.

Souvenez vous..

Bonus : Un simulateur de vol

Plutot que de s’embêter à faire un rendu réaliste d’un terrain avec la faible puissance de l’époque, il était plus simple de faire se déplacer une caméra sur un terrain en taille réduite.

Espace d’adressage

En effet, windows 32 bits (xp ou vista) utilise le mode “32 bits” des processeurs x86. Cela veut dire notamment que l’adressage mémoire se fait avec un pointeur 32 bits (ce n’est pas la seule différence mais c’est celle qui peut vous affecter en pratique). Comme la mémoire peut-etre lue et écrite de 8 bits en 8 bits (octets) et que ce n’est pas négotiable pour raisons de compatibilité, un pointeur 32 bits peut pointer linéairement vers 2^32 octets = 4 giga octets. Grace aux mécanismes de mémoire virtuelle et de swapping to disk, une application pourrait allouer 2Go de ces 4Go, meme s’il n’y a que 512Mo de mémoire physique disponible sur la machine et meme si il y a d’autres applications qui font la même chose (chaque application peut réserver ces 2Go tant qu’il y a de la place sur le disque dur). Où sont les 2Go manquants ? Les adresses hautes (>= 2 ^31) sont réservées pour le noyau de l’OS. Elles ne sont pas directement adressables par les applications.

2Go c’est beaucoup, mais peu en même temps. À l’époque ou cette limite a été mise en place, il n’y avait que des machines avec 1Mo de mémoire, voire 2Mo si on était chanceux, et la situation était pire parce que les programmes tournaient en mode 16 bits et donc ne pouvait adresser que 64 ko de mémoire à la fois et donc devait passer d’une banque de mémoire à l’autre via un selecteur de segment (ce qui rallentit le processeur et peut compliquer la programmation). Passer au modèle de mémoire “plat”, où toutes les adresses sont équivalentes a donc de gros avantages en rapidité et en simplicité de fonctionnement.

Ce n’est donc pas un problème tant que les programmes n’ont besoin que de 2 Go de données. Seul problème, les ordinateurs sont désormais livrés couramment avec 2Go ou 4Go de mémoire physique disponible et une application ne pourrait donc pas adresser la totalité de la mémoire disponible du moins pas directement avec le modèle “plat”. De plus, outre les 2Go constamment occupés par le noyau windows (meme s’il n’en a pas besoin autant), une grosse partie de l’espace d’adressage peut-être consommé de manières diverses et variées, par exemple un programme peut faire un “mapping virtuel” de certaines adresses sur des resources qui ne sont pas en mémoire système, comme la mémoire vidéo de la carte graphique (1Go), un fichier sur disque, ou même réserver de l’espace virtuel non utilisé tout simplement parce qu’il prévoit un gros besoin de plage d’adresses contigues.

Lorsque l’espace d’adressage est utilisé à son maximum, toute nouvelle allocation mémoire ou reserve de plage d’adresse va échouer même si les ressources systèmes autres sont utilisées à 50%. Cela peut également arriver si l’espace d’adressage est fragmenté, et contrairement aux disques durs, un espace d’adressage ne peut pas être défragmenté à part en désallouant tout et réallouant à la volée (puisque le programme conserve les adresses sous forme de pointeurs).

La situation n’est certes pas aussi noire que ça : peu de programmes vont aujourd’hui utiliser 2Go d’adresses. Si il y a 4Go de mémoire physique disponible, la partie qui n’est pas utilisée par un programme peut-etre utilisée par un autre et donc limiter l’utilisation du fichier d’échange, elle peut meme être utilisée comme un cache disque qui n’est pas lié à une adresse fixe. Mais pour les programmes qui vont avoir besoin de plus de 2Go d’adresses ce problème est critique. Dans cette catégorie il y a les jeux vidéo sur PC.

Adresses 64 bits

Sur une machine qui supporte les pointeurs 64 bits, l’espace d’adressage est égal à 4Go fois 2^32, soit plus de 18 milliards de milliards d’octets adressables. Par application.

Donc imaginez vous dans cette situation dans un futur proche : vous avez deux options. La première est de travailler dans un espace restreint, ou vous devez constamment vous demander comment vous allez faire rentrer une nouvelle donnée, aliaser des plages d’adresses (une adresse va pointer sur X ou sur Y suivant la partie du programme que vous executez), et faire l’impasse sur les 2Go de mémoire disponible sur votre carte graphique (ça c’est une feature de vista mais bon vaut mieux pas s’attarder là dessus..), et les 14Go sur 16Go de mémoire DRAM que vous avez acheté pour votre PC qui ne sont pas accessibles parce qu’il n’y a que 2Go qui sont adressables directement. Deuxième option : passer à un système 64 bits avec adressage “plat” (donc pas d’aliasing et espace contigu disponible à gogo) et programmer comme vous l’avez toujours fait.

Pourquoi tout le monde n’est pas encore passé au 64 bits ?

• les processeurs avec adressage 64 bits ne sont couramment utilisés et livrés dans 100% des PC que depuis peu.
• les principaux OS 64 bits ne sont pas des OS grand public (unix, linux et windows pour Itanium).
• l’OS grand public windows XP a une version 64 bits qui est resté en phase beta pendant très longtemps (Microsoft préparait Vista en même temps) et dont la diffusion reste confidentielle. Du coup peu de matériel a les drivers correspondants 64 bits (à moins que ce soit la cause et non la conséquence. la poule et l’oeuf tout ça).
• Vista 64 bits est sorti récemment et va donc peut-etre changer la donne. À cause du problème des drivers, il est probable qu’il faille encore construire la machine sur mesure mais de plus en plus de matériel a des drivers, de plus Microsoft impose un nouveau “logo program” qui combine la certification 32 bits et 64 bits simultanée, donc plus d’excuse pour les fabricants de matériel.

Do you want to know why your app has z-fighting even when you’re using a 24 bits zbuffer in your 3D app ? Or are you interested to know what is the internal representation of a Z-Buffer and aren’t afraid of the gritty details ? Then read the following : The depth buffer the gritty details.

Après avoir répondu plusieurs fois à des questions similaires dans les forums du web, il est facile de se fatiguer à force et il devient difficile de répondre suffisamment bien pour éduquer les gens.

L’une des questions qui revient à tout coup est “pourquoi mes objets disparaissent, ont des artefacts liés au Z-Buffer (Z-Fighting)”. Donc plutôt que de répéter une réponse incomplète (“il faut déplacer le plan proche un peu plus loin”), je préfère rédiger une réponse qui couvre largement le sujet à laquelle les gens peuvent se référer et s’ils sont vraiment intéressés peuvent jeter un oeil aux maths pour prendre une meilleur décision par eux-même. Cela n’est pas votre FAQ typique parce que ça ne répond pas à une question en particulier et parce que vous aurez plus de détails que vous pouviez demander.

Ceci dit, vous pouvez aller lire l’article là bas : Le depth buffer - ce qu’il faut savoir.

Qualité du process de production

Lorsque vous construisez des systèmes complexes avec des traits caractéristiques dont la taille ne dépasse pas le micromètre, voire approchent du nanomètre, vous savez probablement que des erreurs dans la construction de ces systèmes sont inévitables. La moindre poussière dont notre monde est rempli apparaitra de la taille d’un boing 747 ou d’une montagne une fois rapporté à ces échelles microscopiques. De même les défauts dans la structure atomique du substrat qui composent votre gaufrette de silicone (wafer) vont affecter négativement le fonctionnement de votre puce. Bien entendu les usines qui produisent ces puces ont des atmosphères filtrées et sont entièrement automatisées pour réduire l’impact des êtres humains pourvoyeurs de poussière. Mais même dans ces conditions les possibilités d’erreur sont là.

La possibilité de voir une erreur apparaître est dépendante de la qualité du process de production. Paradoxalement les process archaïques mais éprouvés ont une faible probabilité d’erreur. Au contraire les méthodes hi-tech qui poussent plus loin les limites de ce qui est faisable en terme de taille de gravure et de nombre de couches superposées vont être plus soumis aux risques d’erreur.

La formule du yield

Ceci dit en général on raisonne en terme de process donné. Tout simplement parce que le choix de ce process est fait pour des raisons externes. D’une part il n’y a pas tant de fondeurs que ça et d’autre part la pression du marché fait que l’on devra migrer tôt ou tard sur un process qui nous permettra de monter en fréquence et d’augmenter la taille de la puce. Et la plupart du temps la qualité du process n’est pas quelque chose qui est directement influençable (même s’il doit rentrer en ligne de compte dans les coûts du silicium).

La formule du yield est une mesure statistique, du nombre de chips défectueux en fonction du nombre d’erreurs par unité de surface. Elle considère d’une part que la disposition de ces erreurs est totalement aléatoire et uniforme sur la surface du wafer. Donc la distribution est totalement caractérisée par cette quantité (ou probabilité) d’erreurs par unité de surface et la gravité de ces erreurs est identique (on reviendra sur cela plus tard). Et donc le résultat d’une erreur sur la surface du chip est une puce défectueuse.

Il y a plusieurs modèles pour les défauts, celui que j’ai énoncé est celui d’une loi de Poisson et qui n’est pas forcément vraie dans la réalité mais suffira pour la démonstration. Dans ce modèle (distribution totalement aléatoire et uniforme), la probabilité qu’une puce ait au moins un défaut et donc soit défectueuse est 1 - exp(-AD). A étant l’aire couverte par la puce et D étant la probabilité d’erreur par unité de surface. Cette formule du yield va déterminer la quantité de puces que l’on peut produire par wafer.

Influence de la taille

On voit donc que si l’on construit une puce grosse on est doublement perdant, d’une part parce que pour une taille de wafer donnée on pourra mettre moins de grosses puces que de petites puces (et ce n’est pas une relation strictement linéaire à l’aire, parce qu’au fur et à mesure que la puce augmente, la quantité de surface non utilisable sur les bords augmente aussi), et que parmi cette quantité réduite de puces une plus grosse proportion sera non fonctionnelle. Cela se voit dans la formule lorsque l’aire devient très grande, l’exponentielle tend vers zèro et la proportion de puces défectueuse tend vers 1. La limite est bien entendu la taille du wafer et même s’il est théoriquement possible de faire une puce qui couvre toute la surface utile du wafer, on se ruinerait en silicium à vouloir en sortir ne serait-ce qu’une seule puce fonctionnelle.

Influence sur les coûts

Les systèmes de facturation sont variables d’un fondeur à un autre et d’un contrat à un autre. Le modèle économique du fondeur (qui fabrique la puce) n’est pas forcément le même que de celui de son client (qui a commandé la puce au fondeur). Ce qui fait qu’il n’est pas forcément évident d’établir des lois toutes faites pour extraire de la formule du yield, celle des coûts et des potentiels revenus issus de la vente de la puce.

Par contre ce qui est clair c’est que le yield influence directement la capacité de production et donc la capacité d’inonder le marché de puces fonctionnelles et de répondre à la demande. Ceci dit dans l’industrie du semi-conducteur il n’est pas rare qu’une meme entreprise ait deux modèles simultanés, l’un reposant sur une puce facile à produire en grande quantité et à faibles marges, et une autre puce reposant sur une construction plus complexe, avec un faible débit mais en contrepartie des marges à la vente plus élevées. Déterminer à l’avance quel modèle va créer le plus de revenu pour l’entreprise n’est pas forcément évident.

Utilité de la redondance

On a déterminé naïvement qu’une puce plus grosse va influencer négativement la capacité de production (et si ce n’est le coût, au moins la capacité à faire de l’argent). Mais cela n’est pas toujours vrai. Dans certains cas, faire des puces plus grandes va avoir des conséquences positives à la fois sur la capacité de production et sur les revenus.

Une puce aura toujours une taille minimale nécessaire pour implémenter ses fonctionalités et pour atteindre une performance cible. Mais ceci dit on n’est pas forcément satisfait du yield initial d’une telle puce. On peut faire le choix de couper des fonctionalités ou de couper de la performance pour atteindre un yield plus raisonnable. Mais ce faisant on risque de changer de segment de marché, empiétant sur les plates bandes des produits des gammes inférieures ou d’être mis à mal par la concurrence. De même passer du temps pour optimiser le design pour réduire sa taille, peut signifier un retard important qui se traduira par une introduction tardive et une plus faible résistance aux actions de la concurrence. Ou on peut choisir de prendre le chemin de la redondance.

La redondance est le procédé qui consiste à rajouter des unités doublons, qui peuvent être désactivées sans invalider la puce. Le procédé est fréquemment utilisé pour les processeurs comme ceux d’Intel dont la moitié de la surface est prise par la mémoire cache. La mémoire cache est une unité relativement simple par rapport au reste de la puce mais qui prend une large place par simple duplication d’unité de base. Qu’est-ce qu’on y gagne ? direz-vous, on peut certes désactiver une unité défectueuse mais en contrepartie on doit payer le coût de cette unité superfétatoire.

Imaginez qu’une erreur fatale si elle arrive a 50% de chance d’arriver dans une de ces unités doublon si elles couvrent la moitié du chip. Le yield consistera donc comme ci dessus de la totalité des puces ayant zéro erreur, à cela s’ajoutera la moitié des puces qui auront une erreur, etc. Si il y avait typiquement une erreur par puce, cela peut donc faire passer une puce du statut de “non produisible”, à une puce au yield acceptable et cela pour une inactivation de x% de ses transistors. Inversement si le yield était déjà à 90% sans redondance, ajouter de la redondance peut faire avancer le yield vers 95% mais en contrepartie de x% moins de puces par wafer, et donc ce n’est pas toujours un bon choix.

Là encore il y a un choix économique à faire. Multiplier les unités strictement par deux en pratique diminue le nombre maximal de puces produisibles par plus de deux (en comptant les déchets). Pour y gagner il faut donc que l’augmentation du yield soit également supérieure à deux.

Conclusion

Le sujet est vaste, il y aurait encore beaucoup à en dire, mais j’espère qu’il aura contribué à vous faire voir de manière un peu plus clair la notion de yield et ses conséquences sur la production de microprocesseurs. Envoyez vos questions à <>

Scoop : la version 10 de direct3d ne va pas révolutionner le gameplay des jeux. Mais ce n’est pas trés important puisque cette nouvelle release est entièrement et uniquement dédiée au graphisme ! Avec un peu de chance vous jouerez toujours aux mêmes FPS sous de nouveaux noms l’an prochain ;). Ce qui suit va donc uniquement parler du côté technique des jeux. Pour les tests, il y a les sites spécialisés.

Lisez la suite sur l’article : High dynamic Range. En français, comme son titre ne l’indique pas.

Il y a probablement beaucoup de bla blah déjà connu pour ceux qui sont familiers avec le sujet, mais j’espère apporter un point de vue un peu plus détaillé que ce qui est généralement fait.

C’est une preview, la page 2 suivra dans quelques jours hopefully, merci de me signaler les bugs, fautes et autres incohérences.

There have been some improvements since then, explanations on this page (in english): A voxel terrain engine design in C++

Le lien ci-dessus pointe vers un nouvel article, plutot court (comparé au marathon de plusieurs mois consacré au raytracing), consacré comme l’indique le titre au rendu de terrain par voxel. La principale source d’inspiration étant Outcast qui m’avait beaucoup impressionné par son rendu lorsque les polygones étaient encore balbutiants. Le design de ce moteur avait commencé en 1999. Vous pouvez lire l’article en français à l’adresse suivante : Design d’un moteur de terrain par voxel en C++.

Les notions abordées sont aussi diverses que : balayage et écriture d’un fichier TGA, intersection rayon/sphère, lecture d’un fichier config, éclairage de lambert, phong, blinn-phong, correction gamma et format sRGB, formule de Snell-Descartes, formule de Fresnel, réfraction, réflexion, bump mapping, surfaces isopotentielles (blobs), texture d’environnement cubique, adressage cubique, filtrage bilinéaire, bruit de Perlin, textures procédurales, roulette russe, importance sampling, suréchantillonnage (oversampling et supersampling), loi de Beer, aberration chromatique, format HDR et tone mapping, profondeur de champ (depth of field), kd-tree, illumination globale, photon tracing/photon mapping, caustiques et interréflexions et un raton laveur.

You can find on the link above an old article on the raytracing that I reformated for my main web page (it was originally published as a serie of posts on a discussion board). The articles and the source code comments are in french.

Option 1 : Square pixels (default)
    Option 2 : Force ratio 4/3 (1024x768)
    Option 3 : Force ratio 5/4 (1280x1024)
    Option 4 : Force ratio 16/10 (1600x1050)
    Option 5 : Force ratio 16/9 (1600x720)

Les nombres entre parenthèse sont la résolution native équivalente.

Si par exemple le joueur sélectionne la résolution de jeu 1024x768 avec un force pixel ration de 5/4 (pour jouer sur son écran LCD), alors le jeu devra compenser en considérant que les pixel sont étirés verticalement. Cela peut se faire en jouant sur les matrices de transformation dans le pipeline graphique.

Le mode portrait (écran tourné à 90 degré par rapport au mode paysage) n’est pas très courant mais peut-être pris en compte également. Lorsque ces modes exotiques (portrait, 16/9) sont utilisés, se posent des questions douloureuses de gameplay; ou comment éviter que l’une ou l’autre catégorie de joueur se retrouve avantagée, handicapée par le nombre de choses affichées à l’écran. Mais c’est un autre problème.

Une question qui semble souvent bloquer sans raison les débutants en programmation est le tri sur plusieurs critères.

En général la première des choses que l’on apprend en cours d’algorithmique est la fonction qsort. Et en général on trie des entiers n selon une simple fonction compare qui retourne qui de n1 ou n2 est le plus grand.

Maintenant là où ça se complique c’est si l’on introduit plusieurs critères de tri comme le nom, puis le prénom puis la date de naissance et le lieu de naissance. C’est facile à faire dans Excel mais comment faire pour le programmer ?

La chose essentielle à comprendre c’est que tri multicritère == tri à un seul critère. Et oui si l’on sait faire l’un on sait faire l’autre.

struct foo {
  int a;
  int b;
  int c;
};

Imaginons qu’on ait un tableau de struct foo que l’on désire trier selon a puis selon b puis selon c sans devoir réécrire la fonction qsort, introduisons la fonction compare ci dessous :

int compare (void *foo1, void * foo2) {
  foo *truefoo1 = (foo *)foo1;
  foo *truefoo2 = (foo *)foo2;
  if (truefoo1->a - truefoo2->a != 0)
    return truefoo1->a - truefoo2->a;
  else if (truefoo1->b - truefoo2->b != 0)
    return truefoo1->b - truefoo2->b;
  else
    return truefoo1->c - truefoo2->c;
}

et ensuite il suffit d’appeler qsort sur notre tableau de valeur:

qsort(arrayoffoo, n, sizeof(foo), compare);

Et notre tableau sera trié.

Voilà : l’algorithme ne change pas, seule la fonction compare doit maintenant prendre en compte trois critères pour définir l’ordre des éléments entre eux.

Digression: une autre manière de trier des objets sur plusieurs critères a été mis à profit par les machines à trier des premiers recensements. Il s’agit de trier les objets dans des seaux (buckets) en plusieurs étapes et de maintenir l’ordre relatif des objets à l’intérieur d’un même seau. Si l’on trie selon prénom, alors on triera selon nom en faisant en sorte que pour un même nom l’ordre des prénoms soit maintenu. En bout de chaine on aura donc une liste triée correctement selon les deux critères. Si c’est particulièrement adapté au tri mécanique, cela a aussi donné naissance à un tri super rapide des entiers sur ordinateur : le tri radix.

http://www.massal.net/article/stereovision.pdf (forgive the quality of the paper which is equally bad. I just keep it for curiosity purpose.)

Je ne suis pas sûr qu’il y ait un mot différent pour trois vues différentes (ou plus) mais ce papier s’appelle stéréovision tout de même. Bien évidemment comme c’était mon premier vrai projet en C++, je me suis battu en même temps pour apprendre le langage (introduction à la STL et tout ça). J’imagine que si je le faisais aujourd’hui je trouverai tout cela tellement facile.. Le papier est gardé comme objet de curiosité principalement même s’il y a quelques idées à glaner si vous débutez.