Microsoft WARP

Une des nouveautés du dernier SDK Direct3D de novembre est l’addition de la librairie de rendu graphique WARP version 10. Les vieux croûtons (geeks) qui traînent ici penseront soit à Star Trek, soit à Super Mario Bros, soit à OS/2 d’IBM. Mais ça n’a vraiment rien à voir.

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.