Il y a quelques jours maintenant, Sony a levé le voile sur sa console de nouvelle génération en présentant non seulement le design mais aussi des trailers des premiers jeux. Si la réaction a été dans l’ensemble extrêmement positive, certaines voix se sont pourtant élevées pour souligner l’absence d’un véritable saut générationnel. Le fossé avec la PS4 que certains espéraient n’était pas assez conséquent à leurs yeux. Mais est-ce réellement le cas ? Sony s’est-il montré trop conservateur au moment de concevoir l’architecture de sa nouvelle machine ou bien s’agit-il simplement d’une impression ? D’une façon plus générale, le modèle habituel d’une nouvelle génération de consoles tous les 5–6 ans a-t-il toujours du sens ?
Un ralentissement technologique
De 1986 à 2003, l’industrie des semiconducteurs a connu une période faste durant laquelle les microprocesseurs doublaient leurs performances tous les un an et demi environ. Cette augmentation exponentielle de la puissance des puces étaient le résultat de la combinaison de plusieurs facteurs :
L’augmentation de la fréquence
Pas besoin d’explication, un simple exemple pour illustrer devrait suffire : en 1986 le 80386 tournait à 16MHz, moins de 20 ans plus tard en 2003 le Pentium 4 atteignait 3,2GHz soit une fréquence 200 fois plus rapide. En simplifiant, on peut dire que la fréquence doublait tous les deux ans environ.
Des avancées majeures dans les techniques d’exécution des instructions
Pendant des années les architectes des microprocesseurs ont déployé des trésors d’imagination pour améliorer les performances de leurs puces. La plupart de ces techniques avaient pour but de maximiser le parallélisme d’instructions (Instruction level Parallelism ou ILP). A cette époque, la recherche était très active et la concurrence féroce : un grand nombre d’architectures RISC tentaient de s’imposer notamment IBM et Motorola avec l’architecture PowerPC, Sun avec son architecture Sparc, MIPS Computer et son architecture MIPS ou encore Digital et son architecture Alpha. Cette situation a conduit à de nombreuses innovations qui ont posé les bases de l’architecture d’un microprocesseur moderne.
Pendant ce temps, intel le leader du marché, ne restait pas les bras croisés et continuait à améliorer constamment son architecture x86 en s’inspirant des avancées du monde RISC. Ainsi, là où il fallait plusieurs cycles à un 80386 pour exécuter une instruction, le 80486 a introduit la notion de pipeline. Cette technique permet le recouvrement de l’exécution des des instructions et donc un débit d’une instruction par cycle. Le Pentium qui apparaît quelques années plus tard va encore plus loin avec son architecture superscalaire permettant d’exécuter plusieurs instructions par cycle. Enfin, le Pentium Pro en 1995 a introduit des concepts majeurs qui ont posé les bases des architectures modernes : l’exécution des instructions dans le désordre et l’exécution spéculative grâce au renommage de registres. Ces techniques avaient pour but de maximiser l’utilisation des désormais nombreuses unités d’exécution disponibles.
La mémoire cache
Là encore le titre se suffit à lui même. Alors que la fréquence des processeurs augmentait très rapidement, celle des mémoires dynamiques (DRAM) n’arrivait pas à suivre et la latence (le temps entre lequel le microprocesseur faisait une requête mémoire et celui auquel il obtenait la réponse) devenait de plus en plus importante. Pour combler ce problème, les architectes ont introduit la notion de mémoire cache : des petites mémoires statiques extrêmement rapides qui permettent d’éviter au processeur d’interroger la mémoire centrale. Le 80486 a introduit un cache de niveau 1 de 8Ko intégré directement sur la puce. Le Pentium a doublé ce cache avec 8Ko pour les données et 8Ko pour les instructions et enfin le Pentium Pro a intégré le cache de niveau 2 dans la puce. Depuis les améliorations ont consisté à augmenter la taille et la performance de ces mémoires caches et à introduire un niveau 3, voire un niveau 4 de mémoire cache mais avec des améliorations de performance à chaque fois plus modestes.
La fin de l’âge d’ôr
Pourtant cet âge d’or allait rapidement toucher à son terme. Dès la fin des années 90, il devint vite évident qu’extraire davantage de parallélisme du code devenait très compliqué et qu’augmenter le nombre d’unités d’exécutions aurait des effets négligeables voire nuls. Afin de contourner cet écueil, les fabricants de microprocesseurs, intel en tête, ont décidé de tout miser sur la fréquence : puisqu’on ne pouvait pas exécuter plus d’instructions par cycle, il suffisait d’exécuter ces instructions plus rapidement.
L’exemple incontournable de cette stratégie est l’architecture Netburst du Pentium 4. Alors que les microprocesseurs atteignait à peine une fréquence de 1GHz au début des années 2000, intel prévoyait une roadmap très ambitieuse pour son Pentium 4, qui était lancé à une fréquence de 1.5GHz à la fin de l’an 2000, et atteignait 2GHz quelques mois plus tard avant de monter à 3GHz moins de deux ans après son lancement. Mais l’objectif ultime d’intel avec cette architecture était beaucoup plus ambitieux, le géant de Santa Clara visait les 10GHz.
Intel ne fut pas la seule entreprise à miser sur cette approche et à échouer à atteindre ses objectifs de fréquence. IBM appliquera la même stratégie avec son POWER6 qui atteindra 5GHZ mais fera machine arrière avec son POWER7 qui reviendra à une architecture plus équilibrée. Un autre exemple célèbre de ce type d’architecture de type “speed demon” était le PB core (officiellement PowerPC-boosted core, officieusement PlayBox core) d’IBM : le PowerPC qui sera utilisé au sein du Cell et du XCPU. Visant initialement les 4GHz il devra se contenter d’une fréquence légèrement supérieure à 3GHz et restera surtout dans les mémoires pour ses performances anémiques. Avec son long pipeline, son design “in order” et de multiples limitations d’architecture, il aura fait cauchemarder toute une génération de programmeurs de jeux vidéo. Pour la petite histoire, Microsoft mesurera plus tard les performances obtenus par ce design sur du code standard issu de vrais jeux et ce core atteindra un IPC (Instructions par cycle d’horloge) de 0,2 ce qui est très faible. A titre de comparaison un core Jaguar, pourtant loin d’être un foudre de guerre, obtenait 1 dans les mêmes conditions. Puisque nous évoquons le Jaguar nous pouvons en profiter pour rappeler qu’à la même époque AMD a également tenté une architecture visant les hautes fréquences appelée Bulldozer, là encore sans grand succès et la firme de Sunnyvale fera machine arrière des années plus tard avec son architecture Zen.
AMD, IBM, intel ont donc tous tenté ce type d’architectures et ont tous échoué car cette approche, a priori logique, s’est heurtée à des écueils majeurs notamment en termes de dissipation thermique. Beaucoup de gens connaissent mal la loi de Moore et l’associent à tort à l’augmentation des performances des microprocesseurs. En fait, la loi de Moore était simplement l’observation que le nombre de transistors dans un circuit intégré doublait tous les ans environ (cette prévision initiale fut révisée dix ans plus tard en modifiant la période à deux ans). La loi de Moore n’évoque pas les performances, pour cela il faut se tourner vers son corollaire : la mise à l’échelle de Dennard. Cette observation faîte en 1974 par un chercheur d’IBM du nom de Robert Dennard stipule très grossièrement qu’à chaque génération, la densité de transistors double et dans le même temps la fréquence peut augmenter de 40% tout en conservant une consommation énergétique constante. Mais en 2003 cette règle allait arriver brutalement à son terme, se heurtant à des obstacles physiques impossibles à surmonter.
De 2003 à 2011 avec la fin de la mise à l’échelle de Dennard et les difficultés à extraire plus de parallélisme d’instructions l’amélioration de performance des microprocesseurs a brusquement ralenti. S’il ne fallait que 2 ans pour doubler les performances d’un microprocesseur dans les années 90, il en faudrait 20 au rythme actuel ! Mais la loi de Moore en revanche était toujours d’actualité et il fallait donc trouver un moyen d’utiliser tous les nouveaux transistors qu’il était possible d’incorporer sur une surface de silicium. La réponse des ingénieurs a donc été de multiplier le nombre de “cores” sur une puce : d’abord deux, puis 4, puis 8 et enfin 16 dans des machines grands publics disponibles actuellements et jusqu’à 64 dans des machines professionnelles. Dans le même temps, la fréquence stagnait entre 3,5GHz et 4GHz et la consommation aux alentours des 100W comme l’illustrent le graphique suivant.
25 ans de Playstation
Assez de théorie, intéressons nous maintenant à nos différentes générations de consoles. Le tableau suivant résume quelques unes des caractéristiques des générations successives de Playstation. Il est loin d’être exhaustif mais suffit déjà à tirer quelques observations.
On remarque rapidement que les 3 premières générations de Playstation ont suivi la cadence de l’évolution technologique avec des sauts de performance brute d’environ x10 tous les six ans. En 2013, sans surprise avec la fin de la mise à l’échelle de Dennard quelques années auparavant, cette tendance s’est brutalement ralentie. Il convient toutefois de relativiser un peu : la PS4 a marqué un changement de paradigme dans la conception des consoles de Sony.
Comme Mark Cerny l’a indiqué lors de la présentation de la PS4, cette génération marquait la fin des architectures exotiques favorisées par Ken Kutaragi, au profit d’une architecture calquée sur le PC. Par conséquent les chiffres sont difficilement comparables.
Comme nous l’avons vu plus haut, le core PowerPC du Cell, malgré sa fréquence très élevée, était extrêmement peu performant et un core Jaguar à fréquence égale était 5x plus performant en moyenne. Aux fréquences finales des deux puces il y avait donc un facteur x2,5 en dépit de la différence massive de fréquence. Et surtout, la PS4 disposait de 8 coeurs Jaguars contre un seul PPU pour la PS3. Alors certes la PS3 disposait aussi de 7 SPU mais leur rôle était quelque peu différent.
En effet, le RSX, le GPU Nvidia de la PS3 était un peu dépassé en 2006 comparé au Xenos de la Xbox 360 qui disposait d’une architecture plus moderne à base de shaders unifiés. Les SPU du Cell ont dont majoritairement été utilisés par les développeurs pour assister le RSX : une de leurs tâches était notamment d’éliminer le maximum de triangles avant de les envoyer au GPU afin de soulager le pipeline géométrique de ce dernier. La PS4 de son côté disposait d’un GPU moderne qui n’avait pas besoin de ce type de prétraitements, son GPU était aussi capable d’effectuer des calculs génériques (compute shader) de façon asynchrone. Par conséquent, une manière plus logique de comparer les deux machines serait de comparer les SPU additionnés au RSX d’un côté face au seul GPU de la PS4 : soit 405GFlops contre 1,84Tflops, un rapport de x4,5 environ.
En pratique, j’ai un peu simplifié les choses : certaines resources ne sont pas accessibles par les jeux, que ce soit sur PS3 et PS4 mais c’est uniquement pour donner une idée de l’ordre de grandeur. De la même façon, je me suis montré généreux avec la PS4 en considérant un x6,9 pour la bande passante vers la mémoire principale ce qui est injuste vu qu’il s’agit d’une mémoire unifiée partagée entre le CPU et le GPU, pour bien faire il faudrait comparer la bande passante totale de la PS3 : 46,4Go/s face au 176Go/s de la PS4 et donc un rapport de 3,8x seulement. Il y a en revanche une caractéristique de la PS4 qui a pu assurer le rapport habituel des changements de générations : la quantité de mémoire embarquée. Avec 8Go comparé à deux pools de 256Mo sur PS3 on a un rapport x16 qui est même plus important que ce que l’on observait aux générations précédentes. Mais hormis ce point là, les rapports x10 observés précédemment ont laissé la place à des rapports x5 lors de la transition PS3 vers PS4.
Et les choses ne s’améliorent pas avec la PS5 en effet les rapports x5 ont cette fois laissé la place à des rapports x2 à une exception près, mais celle-ci est de taille : la vitesse du SSD comprise entre 5,5 et 9Go/s voire plus selon l’efficacité de la compression, marque un rapport de x100 par rapport à la PS4 ! Deux ordres de grandeur, en d’autres termes c’est un peu comme si on avait sauté une génération : un SSD SATA de 500–800Mo/s aurait déjà marqué un changement appréciable face à la PS4 mais Sony (et Microsoft aussi dans une moindre mesure) a décidé d’aller beaucoup plus loin avec ce SSD sans égal à l’heure actuelle même sur PC. Avant que certains ne me reprennent, je préfère préciser qu’évidemment d’ici à la fin d’année, des SSD encore plus performants seront disponibles sur PC mais ils ne bénéficieront pas de tous les autres avantages d’un hardware fixe et d’une couche logicielle parfaitement adaptée, ce qui est beaucoup plus difficile à obtenir sur PC comme le rappelle Tim Sweeney.
Du point de vue de Sony, il est donc compréhensible de mettre autant l’accent sur le SSD car c’est clairement le point qui marque un vrai changement de génération avec la PS4. Mais le SSD ne doit pas être l’arbre qui cache la forêt : contrairement à la génération précédente, la quantité de mémoire n’a pas augmenté massivement, de même que la bande passante. Même le gain de puissance de calcul du GPU reste modéré.
Et encore, nous pouvons nous estimer heureux : quand Sony a conçu la PS4, le département CPU d’AMD était clairement dans une mauvaise passe et n’avait pas grand chose à proposer à Sony et Microsoft. Le Bulldozer, son architecture de l’époque qui était peu efficace et consommait énormément n’était clairement pas adapté à une console de jeux. La seule option valable était donc le core Jaguar qui, bien qu’il n’offrait pas des performances exceptionnelles, avait au moins l’avantage d’être petit et de consommer peu. Il est quasiment certain que Microsoft et Sony auraient préféré embarquer 4 coeurs efficaces et cadencés entre 2,5 et 3GHz mais leur partenaire étant incapable de leur proposer quelque chose d’adapté, ils ont dû se résoudre à partir sur 8 coeurs Jaguar à des fréquences très faibles même pour l’époque.
En effet, alors que les CPU des consoles ne dépassait pas les 1,75GHz, en 2013 sur PC il y avait des puces largement plus rapides : intel venait d’introduire son architecture Haswell qui atteignait les 3,5GHz (3,9GHz en Turbo) et qui était largement plus efficace que le Jaguar à fréquence égale. Le rapport de x2,5 en fréquence (et ~x5 en performances) qu’on observe donc entre la PS4 et la PS5 est par conséquent un rattrapage du retard de la génération précédente. Le gain est essentiellement dû à l’utilisation d’un CPU très en retrait en 2013, plus qu’à une avancée majeure des consoles de nouvelle génération. A l’inverse avec des CPU disposant d’une architecture moderne et cadencés entre 3,5GHz et 3,8GHz les consoles actuelles sont beaucoup plus compétitives rapport au monde PC actuel, ce qui est appréciable mais d’un autre côté limitera d’autant plus leur potentiel d’évolution lors d’un prochain changement de génération.
La course à la résolution
Bien que l’augmentation des performances ralentisse, il est un point qui ne faiblit pas, c’est l’augmentation de la résolution de nos consoles. A chaque génération, la résolution a augmenté. Il est impossible de lister toutes les résolutions utilisées par les jeux mais voici pour chaque génération quelques résolutions courantes :
- Playstation : 320x240, 512x240 (122880 pixels)
- PS2 : 512x480, 640x480 (307200 pixels)
- PS3 : 1024x600, 1280x720 (921600 pixels)
- PS4 : 1600x900, 1920x1080 (2073600 pixels)
- PS5 : 3200x1800, 3840x2160 (8294400 pixels)
Entre la Playstation et la PS2, le nombre de pixels a été multiplié par 2,5. Entre la PS2 et la PS3, le nombre de pixels a été multiplié par 3. Entre la PS3 et la PS4, le nombre de pixels a été multiplié par 2,25 et enfin entre la PS4 et la PS5 le nombre de pixels a été multiplié par 4. En d’autres termes, la génération qui connaît l’augmentation des performances de son GPU la plus faible, voit dans le même temps la résolution cible augmenter dans la plus grande proportion !
Une autre façon de considérer les choses est d’observer le nombre d’instructions de shaders par pixel.
Ce qui saute immédiatement aux yeux, c’est qu’en passant de la PS3 à la PS4 le nombre d’instructions arithmétiques par pixels a été multiplié par 4 environ (+300%), à l’inverse entre la PS4 et la PS5 le nombre d’instructions par pixels augmente beaucoup plus modestement : moins de 40%. Ce tableau fait également ressortir une information peu réjouissante : en 4k, la PS5 a environ la même puissance par pixel qu’une PS4 en 1600x900.
Entendons nous bien, tout ceci n’est pas à prendre au pied de la lettre, il s’agit juste de donner une idée intuitive de la différence entre les machines. Il est impossible de résumer la puissance d’une puce à un seul chiffre, le nombre d’instructions flottantes par seconde n’est pas une métrique forcément pertinente : c’est une donnée purement théorique. En pratique avec son architecture RDNA2 bien plus moderne que l’architecture GCN 1.0 utilisée par la PS4, la PS5 devrait s’approcher bien plus proche de son maximum théorique que sa prédécesseure. Mais la même chose était également vraie entre la PS3 et la PS4 et pourtant même dans le pire des cas on ne tombait pas dans cette situation.
Un gain visuel décroissant
Les premières consoles 3D étaient extrêmement primitives : le nombre de polygones était très limité, la résolution des textures faibles et souvent il y avait des raccourcis techniques pour rendre le rendu suffisamment rapide. Ainsi la première Playstation ne supportait pas les calculs flottants, le GTE son coprocesseur arithmétique effectuait tous ses calculs en virgule fixe ce qui limitait la précision du rendu. L’application de textures était également incorrecte car la perspective n’était pas prise en compte afin d’éviter une opération de division particulièrement coûteuse. Les textures ne bénéficiaient en outre d’aucune forme de filtrage ce qui en plus de leur résolution relativement basse engendrait cet effet très pixelisé lorsqu’on s’en approchait. Enfin pour économiser de la mémoire, la Playstation ne disposait pas de ZBuffer, les programmeurs devaient trier les triangles depuis le fond jusqu’au premier plan (algorithme du peintre) ce qui pouvait poser de nombreux soucis d’enchevêtrements de polygones.
La N64 était déjà beaucoup plus avancée d’un point de vue qualitatif, mais sans la puissance brute derrière afin de vraiment pouvoir bénéficier de ces avancées techniques. La Dreamcast a en revanche marqué un énorme changement avec un rendu très propre. A cette époque où les programmeurs étaient extrêmement contraints par les limites techniques, le moindre gain de puissance de la machine avait des répercussions visuelles très nettes. Mais avec le temps, l’augmentation de performances nécessaire pour une amélioration visuelle donnée a augmenté c’est ce qu’on appelle la loi des rendements décroissants. Pour donner un exemple extrêmement caricatural, passer de 600 à 6000 polygones procure une amélioration visuelle plus importante que passer de 6000 à 60000. De la même façon, passer d’un shader de 10 à 100 instructions va plus impacter le rendu que de passer de 100 à 1000.
L’image ci-dessus résume bien l’idée mais est très simpliste, pour être plus concret observons plutôt l’effet de l’augmentation du nombre de polygones sur un célèbre personnage.
Le passage de Mario 64 à Mario Sunshine procure une amélioration visuelle incontestable et pourtant le nombre de polygones a peu évolué : le maillage de Mario Sunshine utilise à peine 1,8x plus de polygones. Gardons toutefois à l’esprit qu’outre le nombre de polygones, il y a aussi l’expérience des graphistes de Nintendo avec les maillages 3D qui a joué. En 1996, ils débutaient complètement avec la 3D, en 2002 toute l’expérience accumulée associée à un nombre de triangles plus importants a porté ses fruits. Le passage de Mario Sunshine a Mario Galaxy est là aussi sensible mais cette fois-ci il a fallut utiliser 3,6x plus de polygones pour avoir une différence visible. Enfin le gain qualitatif du passage de Mario Galaxy à Mario 3D World est beaucoup moins flagrant et pourtant le nombre de polygones augmente là encore de 1,8x soit autant qu’entre Mario 64 et Mario Sunshine mais la différence est sans commune mesure. Là encore, certains pourront dire que Mario n’est pas un bon exemple car c’est un personnage au design très simpliste, design qui avait déjà été façonné par les limitations de l’époque lors de son apparition dans les jeux de plate-formes 2D. Mais il est possible de faire le même exercice sur des modèles plus réalistes tout en obtenant le même résultat.
Bien souvent les joueurs interprètent incorrectement la loi des rendements décroissants et pointent avec véhémence que ça n’a pas de sens car à chaque génération la qualité graphique augmente, mais la loi ne dit pas le contraire : elle dit simplement que ce gain visuel se fait au prix d’un coût sur les performances toujours plus important. Or, la prochaine génération comme nous l’avons vu marque un net ralentissement de l’augmentation des performances.
Le nouveau challenge : la production
Enfin, un dernier point qui peut limiter le gain visuel est l’évolution de l’ampleur des jeux vidéo. Lorsqu’un jeu était conçu par une équipe restreinte de quelques programmeurs et graphistes, sur une machine extrêmement limitée, l’ingéniosité technique faisait la différence. Le moindre petit gain de mémoire était visible lorsqu’on ne disposait que de quelques maigres mega octets, la moindre astuce algorithmique qui permettait d’afficher plus de triangles avait un impact visuel considérable quand on ne pouvait en afficher que quelques centaines à chaque frame. Aujourd’hui, alors que le développement des jeux AAA s’étale sur plusieurs années avec des équipes de parfois plus de 1000 personnes, ce n’est plus le talent d’optimisation qui fait la différence. A cette échelle l’important si on veut aboutir à un jeu au final, c’est avant tout la production. Un nouvel algorithme graphique est jugé non seulement par rapport au gain visuel qu’il apporte mais surtout à l’impact qu’il aura sur le flux de travail, s’il risque de compliquer la vie des graphistes il y a peu de chances qu’il soit intégré. C’est la raison principale pour laquelle il est toujours beaucoup plus simple de faire une démo technologique qu’un jeu fini, car dans ce cas on peut se permettre de prendre des raccourcis.
Alors qu’Epic vient de présenter l’Unreal Engine 5 avec Lumen, son impressionnant moteur d’illumination globale, on a tendance à l’oublier mais il y a 8 ans, ils présentaient l’Unreal Engine 4 qui à l’époque incorporait déjà un moteur d’illumination globale alors basée sur des voxels : SVOGI (Sparse Voxel Global Illumination). Cet algorithme issu des travaux de Cyril Crassin, chercheur chez Nvidia, publiés en 2011 sous le nom de Gigavoxels, tournait de façon interactive sur une simple GeForce GTX480. Alors que l’Unreal Engine 4 ciblait au final des machines beaucoup plus puissantes, l’algorithme d’illumination globale a finalement été retiré avant la sortie du moteur. La raison officielle était que l’algorithme était trop gourmand et ne pouvait pas facilement s’adapter aux petites configurations. Dans la pratique, la technique n’était pas suffisamment robuste, une résolution insuffisante de la structure de voxels conduisait à des artefacts visuels inacceptables comme l’expliquait à l’époque Daniel Wright d’Epic :
De nos jours, chaque technique est donc évaluée ainsi : outre son apport visuel, elle ne doit pas impacter trop fortement le pipeline de production. Si elle nécessite de trop nombreux ajustements des graphistes ou des designers pour éviter les cas pathologiques, il y a peu de chance qu’elle soit intégrée au final.
L’ère du codeur brillant qui s’enferme avec son ordinateur et suffisamment de sodas et ressort avec un moteur 3D révolutionnaire est terminée depuis longtemps. S’il était possible aux débuts des consoles 3D, d’avoir une vision globale extrêmement précise d’une machine et d’en optimiser le moindre cycle, c’est désormais totalement impraticable. Les microprocesseurs de l’époque étaient très simples et entièrement déterministe : chaque instruction était exécuté dans l’ordre dans lequel elle était soumise, il était donc possible d’agencer son code pour maximiser l’utilisation des différentes unités. Aujourd’hui ce n’est plus le cas. Les microprocesseurs modernes et les GPU sont devenus tellement complexes, que même leurs concepteurs ne les maîtrisent pas totalement : les ingénieurs ne connaissent parfaitement que la partie dont ils sont directement responsables.
Si vous pensez que j’exagère, une petite anecdote de Bob Colwell l’architecte du P6 d’intel (Pentium Pro, Pentium II et Pentium III) pourrait achever de vous convaincre : lors de la mise au point de l’architecture, les ingénieurs ont détecté des cas où certaines combinaisons obscures d’instructions et de micro-ops pouvaient complètement bloquer le microprocesseur. La bonne solution aurait été de détecter tous les cas où ça se produisait, de comprendre l’interaction entre les instructions qui provoquait ce blocage et de le fixer. En pratique, il était impossible d’être à 100% sûr d’avoir identifié toutes les situations où cela pouvait arriver. La solution qu’ils ont intégrée consiste donc à mesurer le nombre de cycles écoulés depuis la dernière instruction qui a été effectivement complétée et si ce nombre de cycles excède un certain maximum, ils savent que le processeur est bloqué et le font revenir à un état stable précédent. Comme le résume bien Bob Colwell :
Si vous saviez vraiment ce que vous faisiez, auriez vous besoin de faire ça ? Est-ce qu’en introduisant ce méchanisme on ne camouflait pas notre propre ignorance ?
Aujourd’hui dans les studios de jeux vidéos, l’heure est donc moins à la micro optimisation ce qui ne veut pas dire pour autant que le code des jeux modernes n’est pas efficace, c’est juste qu’avec des équipes aussi conséquentes il n’est plus possible de procéder comme dans les années 90 où on pouvait partir du principe que les quelques programmeurs qui travaillaient sur un jeu maîtrisaient parfaitement le code dans sa globalité et étaient tous extrêmement compétents pour écrire du code performant. Aujourd’hui les équipes intègrent un grand nombre de programmeurs, certains très brillants et expérimentés, d’autres débutants qui sortent juste de l’école. L’idée est donc moins d’écrire le code le plus performant possible mais surtout de mettre en place une architecture qui permette à tout le monde de participer tout en empêchant les débutants d’écrire du code vraiment mauvais d’un point de vue des performances, ce qui peut arriver très rapidement. Les techniques de programmation orientée objet notamment, qui sont enseignées dans les universités et les écoles peuvent engendrer un code catastrophique en termes d’accès mémoire si on n’y prend pas garde. C’est pour éviter cet écueil que les techniques de programmation “data oriented” se sont développées afin de permettre aux programmeurs de tous niveaux de mieux tirer profit des mémoire cache et des microprocesseurs modernes à plusieurs coeurs. Ceci étant dit, il faut garder à l’esprit que les portions de code critiques des moteurs 3D restent la chasse gardée de quelques experts et sont particulièrement bien optimisées.
Certains joueurs se demandent parfois pourquoi des équipes de développement qui faisaient des miracles il y a quelques années ont disparu ou ne sont plus que l’ombre de leur glorieux passé. Je pense notamment à Factor5 ou encore Rare qui réalisaient des petits bijoux techniques du temps de la N64 et ont eu du mal à passer le cap des consoles modernes. L’explication souvent avancée est que ces studios ne sont plus que des coquilles vides, mais cela n’explique pas tout : tous les studios connaissent un turn over important et pourtant certains restent toujours au top de la technique. En pratique ce qui arrive est simple : les développeurs n’ont pas subitement perdus leur expertise technique, mais dans les grosses productions actuelles l’expertise technique ne suffit plus. Ces studios n’ont pas réussi à faire évoluer leur organisation afin de pouvoir suivre les exigences des jeux modernes. En revanche, un studio comme Naughty Dog continue toujours d’impressionner à chacune de ses nouvelles productions et ce bien que les petits génies responsables de Crash Bandicoot il y a 25 ans ont quitté le studio depuis longtemps.
Après ce long déballage technique, il serait intéressant de terminer sur une note positive. L’arrivée d’une nouvelle génération de consoles est toujours un petit évènement et il serait dommage de le gâcher en jouant les rabat-joie. Si certains ont pu s’avérer légitimement déçus par les premières images de jeux nouvelle génération, il convient toutefois de relativiser un peu cette première impression. Une tendance fréquente, consiste à comparer un nouveau jeu à ce qui existe déjà sur le marché et auquel on a déjà joué, le problème c’est que notre mémoire nous joue des tours et enjolive souvent nos souvenirs. On ne compare pas réellement Horizon Forbidden West à Horizon Zero Dawn, mais au souvenir qu’on a d’Horizon Zero Dawn et parfois l’écart entre nos souvenirs et la réalité peut s’avérer être assez important. C’est la raison pour laquelle rejouer à des jeux qui nous avait impressionnés techniquement avec un peu de recul nous fait souvent tomber de haut.
Un autre problème est que pendant un an, la PS5 n’était qu’un fantasme : tout ce dont nous disposions à son sujet était des informations très parcellaires et les joueurs ont pu laisser libre court à leur imagination en songeant à tout ce que cette nouvelle génération pourrait apporter. Mais en pratique, il est difficile de se projeter de manière réaliste surtout quand les rumeurs des spécifications techniques changent souvent et sont la plupart du temps fantaisistes. A partir de là, quels que soient les jeux présentés par Sony, il était quasiment impossible de répondre aux attentes complètement démesurées de certains. Profitons en aussi pour rappeler que comme à chaque génération, les premiers jeux présentés sont loin de faire la meilleure exploitation du hardware. Ils sont conçus avec une connaissance des machines incomplète, sur des kits de développement qui évoluent fréquemment et avec des planning extrêmement serrés.
Enfin, il convient de souligner que nous avons déjà vu de belles choses, au premier rang desquelles la démo d’Epic de son prochain moteur Unreal Engine 5 “Lumen in the Land of Nanite”. Alors certes, il ne s’agit que d’une démo d’un moteur 3D, prévu pour 2021 au mieux, et il subsiste encore de légitimes interrogations sur la plausibilité de concevoir un jeu entier avec ce niveau de détails mais il faut bien reconnaître que cette démo a mis une réelle claque visuelle et laisse présager de belles choses. Qu’il s’agisse de la virtualisation de la géométrie à base de micropolygones (Nanite) ou des techniques d’illumination globale (Lumen) le rendu temps réel a franchi un réel cap et nous sommes impatients d’en apprendre d’avantage sur les détails d’implémentation.
Concernant une hypothétique nouvelle génération post-PS5 et Series X en revanche il semble clair que le modèle traditionnel d’une console tous les 5–6 ans semble approcher de son terme. Le premier signe avant coureur est apparu lors de cette génération avec les modèles intermédiaires : PS4 Pro et Xbox One X. Ces versions améliorées introduites en milieu de génération aurait semblé inconcevables il y a quelques années tant le modèle console du hardware fixe semblait ancré dans les mentalités. A partir de là il est difficile de savoir dans quelle direction les consoles vont évoluer.
A l’image de ce qu’on observe avec les smartphones, les générations vont elles devenir progressivement de plus en plus floues, avec des rafraichissements fréquents plutôt que des “révolutions” tous les 6 ans ? Difficile à dire, mais une chose est sûre, avec l’intégration du SSD dans cette génération, les fabricants ont éliminé le dernier goulet d’étranglement des consoles actuelles et il ne reste plus de cible facile à viser pour marquer un véritable changement de génération dans le futur.