Avant de commencer la lecture de cette nouvelle, sachez que si je l'ai écrite, c'est parce que BalSagoth m'a envoyé un courriel expliquant que cette nouvelle serait un cadeau (ou plutôt une punition pour palier à ma paresse) de la part de Bibi et lui-même. Après avoir lu une première fois le court article de chez Slashdot, je me suis vite rendu compte que traduire l'article serait des plus pénible, mais voilà, j'ai tenté du mieux que j'ai pu de surmonter le défit. Remarquez que j'ai tendance à tout franciser, ou plutôt à utiliser le moins de termes anglophones possible, aussi fut-t-il très difficile de rester fidèle à cette habitude..... bonne lecture. ;)

Slashdot, de par sa célébrité et sa bonne réputation, a quelques fois la chance d'être utilisé comme voix de communication par John Carmack, le génie à qui l'on doit les moteurs 3D de chez id Software (Quake III ARENA, Doom III et autres plus anciens). Ainsi, ce dernier nous parle aujourd'hui de stratégies utilisés par les drivers de cartes vidéos. C'est en fait de ces différentes stratégies que découlent les principales différences entre les cartes de chez ATI et celles de chez Nvidia. On le sait, c'est la confrontation des performances depuis la sortie de la ATI Radeon 9700 Pro qui a balayé la GeForce 4 et qui concurrence voir dépasse également la GeForce FX.

Bon, fini le blabla, entrons dans les détails croustillants. Comme l'avis de Carmack compte pour beaucoup dans l'industrie, il a cru bon de s'imposer contre les magouilles de l'univers de la 3D pour assurer aux développeurs de ne pas avoir à travailler avec des technologies anti-développement. Voici ce qu'il avait à dire d'intéressant... traduit comme j'ai pu, s’abstenir ceux qui n'ont pas un vif intérêt pour le sujet :

La réécriture de shaders derrière une application de façon à changer le résultat dans des circonstances non contrôlées est absolument positivement fausse et indéfendable (pas d'inquiétude, les explications arrivent).

Réécrire un shader (On définira le shader comme une fonction qui applique une ombre sur un objet et qui trace l'objet par la même occasion. Pensez-donc à cette définition lorsque j'utiliserai ce même terme un peu plus loin.) afin qu'il fasse exactement la même chose mais de façon plus efficace est généralement acceptable si on parle d'optimisation lors de la compilation. Il est beaucoup plus aisé de défendre une instruction qui aide pratiquement tout le monde que de défendre un shader précis qui sert seulement à aider une application. La comparaison de shaders est 'moralement grincheuse' (morally grungy), mais pas profondément mauvaise.

La différence qui embrouille la comparaison entre ATI et Nvidia est la précision de la fragmentation des shaders. Alors que Nvidia peut travailler avec des entiers de 12 bits, des entiers à virgule flottante de 16 et 32 bits, ATI utilise toujours des entiers à virgule flottante de 24 bits. Il n'y a pas actuellement de mode où ils puissent être comparés. DX9 et ARB_fragment_program assument des opérations avec des entiers à virgule flottante de 32 bits alors que ATI converti tout à des entiers à virgule flottante de 24 bits. Pour toute opération donnée, une carte Nvidia travaillant avec des entiers à virgule flottante de 16 bits sera plus rapide qu'une ATI alors qu'au contraire, elle sera plus lente lorsqu'elle travail avec des entiers à virgule flottante de 32 bits. Lorsque Doom 3 utilise le shader à fragmentations spécifique au NV30, c'est plus rapide qu'une ATI, alors que si les deux utilisent le shader ARB2, la ATI sera plus rapide.

Lorsque la sortie vidéo utilise une mise en mémoire temporaire des rendues à 32 bits, comme tous les tests le font actuellement, il est possible pour Nvidia d'analyser l'information des textures, constantes et attributs et de remplacer plusieurs opérations à 32 bits pour des opérations à 16 ou même 12 bits sans aucune perte de qualité ou de fonctionnalité. C'est tout à fait acceptable et sera bénéfique pour toutes les applications, mais ça va aussi certainement introduire des bogues très dure à trouver dans le compilateur du shader. Vous pouvez vraiment passer par dessus le bord avec ça -- si vous voulez conserver toute la précision possible, vous devrez examiner les dimensions de chaque texture et suivre [...] (vertex buffer data ranges) pour chaque partie attachée au shader (for each shader binding). Ce serait une décision architecturalement très mauvaise, mais la pression exercée par les benchmarks incite les fournisseurs à de telles pratiques même s'ils évitent de tricher tout à fait. Si des optimisations de compilation très agressives sont implantées, Carmack espère qu'ils incluront une option ou un programme de déboguage qui n'appliquera pas de telles optimisations.

L'article d'origine est tout en anglais, aussi excuserez-vous quelques erreurs de traduction que j'ai pu faire (contactez-moi cependant pour que je puisse les corriger !) Pour ceux qui n'en n'ont pas assez, l'article a été commenté par des centaines de personnes... bref, c'est par ici.