Actualités informatiques du 13-06-2002

NVIDIA vient d'annoncer le Cg, pour 'C for Graphics'. Jusqu'alors, pour programmer des shader, il fallait travailler avec des instructions de type assembleur assez proche du matériel. Avec le CG? On s'éloigne du matériel puisque le Cg se place au dessus de DirectX ou d'OpenGL, ce qui permet de coder en faisant abstraction du hardware.

Avec le Cg, les développeurs pourront écrire leur shader via le language Cg, qui est plus simple et assez proche du language de shader utilisé par RenderMan de Pixar (mais qui est pour sa part réservé au rendu software). Ce shader pourra ensuite être compilé pour une puce DirectX 8, OpenGL 1.4 puis DirectX 9 et OpenGL 2.0 lorsque ces API arriveront en versions finales.

L'intérêt du Cg est double, puisque d'une part il permet de faciliter la programmation des shader de part un langage plus simple et indépendant de l'API ou de l'OS. D'autre part, il est par exemple possible d'écrire un seul shader Cg puis de le compiler pour DX8, DX9 (voir OGL), le moteur de jeu utilisant ensuite le shader adéquat en fonction du GPU présent sur votre PC !

Fong Shader en assembleur

DP3 R0, c[11].xyzx, c[11].xyzx;
RSQ R0, R0.x;
MUL R0, R0.x, c[11].xyzx;
MOV R1, c[3];
MUL R1, R1.x, c[0].xyzx;
DP3 R2, R1.xyzx, R1.xyzx;
RSQ R2, R2.x;
MUL R1, R2.x, R1.xyzx;
ADD R2, R0.xyzx, R1.xyzx;
DP3 R3, R2.xyzx, R2.xyzx;
RSQ R3, R3.x;
MUL R2, R3.x, R2.xyzx;
DP3 R2, R1.xyzx, R2.xyzx;
MAX R2, c[3].z, R2.x;
MOV R2.z, c[3].y;
MOV R2.w, c[3].y;
LIT R2, R2;

Phong Shader en Cg

COLOR cSpec = pow(max(0, dot(Nf, H)), phongExp).xxx;
COLOR cPlastic = Cd * (cAmbi + cDiff) + Cs * cSpec;

Phong Shader avec RenderMan (rendu software)

color cSpec = phong(Nf,V,phongExp);
Ci = Oi * (FinalColor = DiffuseColor * (AmbientLight + DiffuseLight)) + SpecularColor * cSpec;

De plus, le Cg sera un langage ouvert dans le sens ou ses spécifications seront publiées et qu'une version open source du compilateur sera disponible afin que les autres fabricants de GPU puissent développer leurs propres compilateurs Cg utilisant leurs extensions OpenGL propriétaires.

Voilà donc une très bonne innovation qui devrait en théorie accélérer l'arrivée de jeux utilisant les shaders, tout en permettant d'avoir des shaders qui pourront à la fois fonctionner sur des GPU DX8, DX9 (voir plus) ... mais pas à la même vitesse bien entendu.

La balle est maintenant dans les camps des développeurs puisqu'ils disposent déjà d'une première version du kit de développement Cg téléchargeable sur le site de NVIDIA  avec un compilateur supportant les Pixel et Vertex Shader DirectX 8 ainsi que l'extension OpenGL NV_vertex_program. Une seconde version du kit devrait arriver un peu plus tard. Elle intégrera notamment la version finale du compilateur Cg qui supportera DX9, OpenGL 1.4 (ARB_vertex_program) ainsi que les extensions Vertex & Pixel Shader OGL spécifiques au NV30, sans oublier des plug-in 3ds / Maya / Softimage.

La seule réserve que l'on peu émettre se situe au niveau de l'OpenGL. En effet, 3D Labs a fait la proposition à l'ARB d'un langage similaire mais spécifique à l'OpenGL 2.0 (car intégré à celui-ci) et incompatible avec les GPU existants. Si ce langage est accepté par l'ARB dans l'OpenGL 2.0, la cohabitation avec le Cg devrait être difficile. Pour rappel, l'ARB est un consortium crée en 1992 qui se charge de définir les spécifications et les évolutions de l'API OpenGL. Il est composé de 12 membres ayant le droit de vote : 3Dlabs, Apple, ATI, Dell Computer, Evans & Sutherland, Hewlett-Packard, IBM, Intel, NVIDIA, Microsoft, SGI, Sun. Wait & see donc ...

Suite à nos tests, nous pouvons confirmer qu'après OCZ c'est au tour de Mushkin de se faire 'piéger' par le changement de puce opéré chez Samsung (passage de la 3è génération à la 4è génération de DDR333 chez Samsung, cf. notre comparatif). En effet, nous avons pu nous procurer diverses barrettes PC3000 / 3200 Mushkin, équipées soit des puces Samsung révision C ou D. Testée sur P4S5333 avec les timings manuels 2.5-3-3-7-2T, nous avons obtenus les résultats suivants (deux memtest sans erreur en 2.5V pour que la fréquence soit validée) :

Comme vous pouvez le voir, en ce qui concerne les PC3200 256 Mo les barrettes basées sur les puces Samsung DDR333 de révision D ne fonctionnent pas aux spécifications annoncées par Mushkin (200 MHz en 2.5-3-3), et ce que ce soit avec un ou deux barrettes (pas de boot!).


Du côté des 256 Mo PC3000, les Mushkin basées sur les puces Samsung de révision D fonctionne aux spécifications annoncées ... à condition d'être utilisées en mode mono-barrette. En effet, la combinaison de deux modules de révision D n'est plus stable à 183 MHz en 2.5-3-3. Il est à noter que comme les 3200, les 3000 basées sur les puces Samsung C passait en 200 MHz, et ce même avec deux barrettes.


Pour finir, en ce qui concerne les barrettes de 512 Mo PC3000, elles ont fonctionnées aux spécifications annoncées, et ce que ce soit avec des puces Samsung révision C ou D. Toutefois, à 183 MHz la barrette basée sur les puces Samsung révision D est assez limite, d'ailleurs à 200 MHz le PC ne boote pas, alors qu'avec les puces Samsung révision C si (même si à 2.5V memtest donne des erreurs dans cette configuration).

Après OCZ, c'est donc la validation de Mushkin qui est décevante. En effet, si l'on achète ce type de barrettes ce n'est pas seulement pour avoir un joli PCB noir ou rouge, ou encore un joli radiateur ... c'est aussi parce que ce sont des barrettes qui sont censées être certifiées pour allez plus haut que celles de constructeurs tels que Samsung (car dans le cas contraire autant économiser de l'argent pour une barrette Samsung !). Un constructeur de la réputation de Mushkin aurait du réagir de lui-même au changement de qualité des puces DDR333 Samsung et arrêter de suite la production de PC3200 afin d'attendre les puces Samsung DDR400 de 4è génération.

Espérons maintenant que Mushkin réagisse vite face à cette situation et que ce constructeur ne posera pas de problèmes aux utilisateurs ayant fait l'acquisition de barrettes ne fonctionnant pas aux spécifications annoncées.