[News] OpenGL

**Alice** · 05/08/2005, 21h11

Envoyé par fennec

Donc on revient bien à ce que je disait, il faut optimiser spécifiquement le code pour chaque architecture si on veut les meilleures perfs. Le code optimisé SSE2 tournera plus lentement sur un A64 qu'un P4

:heink: ...Optimiser SSE2 ce n'est pas optimiser (que) Pentium4 on est d'accord hein?

Envoyé par fennec

Pour l'A64 il faudrait optimiser en utilisant du code non SSE2

J'ai pas compris ton raisonnement :??: ... Optimiser SSE2 apportera son gain de performance... que ce soit sur Intel ou AMD

**fennec** · 06/08/2005, 00h02

Utiliser des instructions SSE fera gagner en performance sur P4 et Athlon, il n'y a pas de doutes. Mais comme je l'ai déjà dit optimiser ce n'est pas substituer des instructions, il vaut mieux parler de "codepath", c'est a dire, comme fefe l'a aussi dit de profonds changements dans les algoritmes. Un "codepath" optimisé pour P4 a toutes les chances de ne pas offrir le même gain de performances sur un Athlon.

Disons qu'on a un code qui s'execute en 100s sur un P4, après optimisation spécifiquement faite pour le P4 on dit qu'il ne faut plus que 50s. Imaginons qu'on se débrouille pour trouver un cpu Athlon qui fait aussi 100s en code non optimisé, en utilisant le codepath P4 il s'executerait en 75s. Par contre si on faisait un codepath spécifique Athlon il s'executerais peut être en 40s sur l'Athlon et 60s sur le P4.

Ce que je veux dire, c'est que chaque architecture de processeur est unique. Même si elle sont compatibles entre elles au niveau des résultats le comportement interne est totalment différent, de ce fait du code optimisé P4 ne sera pas du tout le même que du code optmimisé Athlon. Quand on fait du code assembleur (ce dont on parlait au début) il faut connaitre l'archi cible sur le bout des doigts, si ce n'est pas le cas il vaut mieux laisser le compilateur faire le boulot et utiliser un language de plus haut niveau. Un code assembleur fait main et qui tourne très vite sur une archi peut être très très lent sur une autre. Il faut donc faire un "codepath" par architecture si on cherche réellement la performance pure.

D'ailleur si la manière d'optimiser pour P4 était la même que pour un Athlon on aurait pas des switch spacifique pour chaque révision de cpu dans GCC par exemple.

Pour vraiment prendre conciense de la complexité d'une archi je te conseille la lecture des articles de xbitlabs sur le P4:

http://www.xbitlabs.com/articles/cpu...etburst-1.html
http://www.xbitlabs.com/articles/cpu...etburst-2.html
http://www.xbitlabs.com/articles/cpu...ay/replay.html

**Alice** · 06/08/2005, 01h55

Je crois que tu t'emballes

. On parle de jeu. Optimiser un jeu en SSE2 c'est généralement (tout le temps?) écrire du code qui tente d'accélérer au mieux l'éxécution de celui-ci aussi bien pour les processeurs Intel, qu'AMD.

Si l'on regarde ce que fait le "Source engine", il détermine au lancement quel "type de code" il va utiliser. Cependant il ne choisit pas un code path spécifique au CPU dans le sens où tu l'entends, il détermine quels sont les jeux d'instructions disponibles afin d'utiliser ou non les optimisations SSE2/SSE/MMX...etc correspondantes. Mais derrière, il y a de forte chance que le code SSE2/SSE/MMX, soit le même pour les Pentium et les Athlons

Si on revient à l'idée de départ:

Envoyé par dandu

Optimiser (en ayant les compétences) des petites parties de codes qui sont critiques (eventuellement en SIMD) en assembleur à la main apporte des gains (parfois énormes).

Oui... c'est d'ailleurs le cas depuis un moment

Envoyé par fennec

éventuellement mais sur une achitechture donnée c'est valable, si c'est du code pour particulier qui va tourner sur des cpu très différents comme un jeu vidéo ça n'a aucun intéret ...

Non. Au contraire. Comme dit auparavant certains moteurs actuels et passés ont ce type d'optimisation. :wink:

**fennec** · 06/08/2005, 20h58

A la base on parlait de coder en assembleur, pas des instruction étendues. Choisir d'utiliser ou non SSE/SSE2 en fonction du type de cpu est effectivement très répendu. Pour ce qui est de coder une partie même petite en assembleur c'est de plus en plus rare et souvent inutile. Tu introduis des risques au niveau de la stabilité sans pour autant garantir des gains dans tous les cas. En fait il faudrait jetter un oeil aux sources du "source engine" vu qu'elle sont plus ou moins dispo :evil:.

**Alice** · 07/08/2005, 00h25

Envoyé par fennec

A la base on parlait de coder en assembleur

Le code optimisé SSE/SSE2 c'est du code assembleur hein :heink: ... ! Non là c’est sur, on est bien d’accord ? C'est bien de ça dont on parlait. Dandu disait d'écrire des parties de code critiques en assembleurs éventuellement en SIMD (Single Instruction Multiple Data implique le SSE/SSE2 (sur x86)).

En somme tu t'es fourvoyé en disant que coder en assembleur pour des jeux ça n'avait aucun intérêt...:wink: J'insiste pour ne pas y revenir :P (et éventuellement te faire avouer que tu avais tord :wink

: "Optimiser un jeu en SSE2 c'est généralement (tout le temps?) écrire du code en assembleur qui tente d'accélérer au mieux l'exécution de celui-ci aussi bien pour les processeurs Intel, qu'AMD. "

Maintenant comme tu l'as suggéré, un petit tour dans le code du source vérifie ce dont on parlait (Du moins pour ce que j'en ai vu) ... En plongeant rapidement le nez dans les entrailles du source on trouve bien de petites parties de codes en assembleur (entre autre, du SSE et du SSE2... si si j'insiste

). Cependant, quelque pars tu n'as pas tout à fait tord puisque effectivement il y a une partie du code assembleur spécial AMD... Mais pas dans le sens où tu l'entends.

Le source est un lointain parent du moteur de Quake premier du nom (Juste pour rappel Half-life utilisait le moteur Quake… enfin… modifié le moteur hein !). On retrouve dans le source des parties de code lui appartenant... Il est presque sur qu’une partie du code assembleur vienne directement de Quake… A cette époque les optimisations assembleur c’était de l’optimisation 3DNow / MMX ; et c’est dans ce sens où il y a une partie du code assembleur spécifique AMD puisque le 3DNow ! est un jeu d’instructions made and use by AMD only… Cependant si le processeur AMD dispose du SSE, le source le lui préfère (Normal

) et utilise alors le code SSE à la place du code 3DNow !

Ceci étant, le code SSE/SSE2/MMX est bien le même quel que soit le processeur détecté…

**fennec** · 07/08/2005, 12h22

Effectivement tu as raison, j'ai bien trouvé aussi du code asm, il y en très peu. Je pense que les fichier .s (venant de Quake1 !) ne doivent pas être très utilisé. Par contre il y a le fichier matlib.cpp qui ne contient que ça. Il y aussi un gros fichier .h avec les macro 3DNOW mais ça ne doit pas être beaucoup utilisé. Mais je trouve ça complètement nul je pensait bêtement que les dev de jeux utilisaient une des nombreuses mathlib exisantes au lui de ré-inventer la roue tout le temps.

**Doc TB** · 07/08/2005, 22h31

Envoyé par Alice

Ceci étant, le code SSE/SSE2/MMX est bien le même quel que soit le processeur détecté…

Ca impliquerais que les instructions SSE/SSE2 soient traitées de la même façon sur tous les CPU, ce qui n'est pas le cas.

Quelque chose me dit que la précision de certaines instructions n'est pas la même chez Intel et chez AMD :whistle:

**fefe** · 07/08/2005, 22h34

Envoyé par Sam D.

Quelque chose me dit que la précision de certaines instructions n'est pas la même chez Intel et chez AMD :whistle:

Toi aussi ?

**PeGGaaSuSS** · 07/08/2005, 22h35

Envoyé par Sam D.

Envoyé par Alice

Ceci étant, le code SSE/SSE2/MMX est bien le même quel que soit le processeur détecté…

Ca impliquerais que les instructions SSE/SSE2 soient traitées de la même façon sur tous les CPU, ce qui n'est pas le cas.

Quelque chose me dit que la précision de certaines instructions n'est pas la même chez Intel et chez AMD :whistle:

Y'a quelqu'un qui a testé en profondeur ces instructions entre Pentium 4 / Pentium M / Athlon 64 pour voir si y'a une nette différence entre les Pentiums et l'Athlon 64 ou plutot le Pentium 4 et le lot Athlon 64 / Pentium M ?

**fefe** · 07/08/2005, 22h37

Jette un oeil aux 1/x et aux racines carrees approximees en SSE.

**PeGGaaSuSS** · 07/08/2005, 22h39

Ouais

J'y connais rien en programmation hein, c'est pour sa que je demande.

**jihef** · 07/08/2005, 22h43

Envoyé par fefe

Jette un oeil aux 1/x et aux racines carrees approximees en SSE.

Tu parles pas plutot du 3DNow plutot ?

**Doc TB** · 07/08/2005, 22h46

SQRTPD :whistle:

**fefe** · 07/08/2005, 22h47

RCPPS, RSQRTPS, je parles de SSE.

SQRTPD devrait etre conforme a la norme IEEE dans tous les cas donc normalement tout le monde est sense repondre la meme chose. les RCP ce n'est pas le cas.

**jihef** · 07/08/2005, 22h48

Envoyé par Sam D.

SQRTPD :whistle:

Vi je connais mais je vois nulle de part de question d'approximation dans une doc :??:

Alors que je suis sur qu'il y'a des instructions qui approximent en 3DNow.

edit : RCPSS et RCPPS ok y'a approx. j'avais pas regardé celles la.

**Doc TB** · 07/08/2005, 22h49

Ca le fait pas en DP ?

**fefe** · 07/08/2005, 22h49

cf mon post cis dessus, ce sont les reciproques qui sont des approximations 12 bits non normalisees.

**Doc TB** · 07/08/2005, 22h50

Ca mériterais pas une news ça ? :D

Faut faire un petit soft rapide pour le démontrer et zou.

**jihef** · 07/08/2005, 22h51

J'avais jamais fais gaffe a ce mot dans la doc "Computes the approximate..."

C'est ecrit dans la doc et c'est pas bien dur a faire meme sans assembleur avec gcc ou le compilo intel.

**fefe** · 07/08/2005, 22h52

Pas vraiment tout le monde respecte les specs. C'est su depuis longtemps. Certains vont juste a plus de bits que d autres d ou resultats differents.

**Lissyx** · 07/08/2005, 23h08

Envoyé par Sam D.

Ca mériterais pas une news ça ? :D

Faut faire un petit soft rapide pour le démontrer et zou.

recenser tous les bugs critiques non corrigés !

**Alice** · 07/08/2005, 23h22

Envoyé par Sam D.

Envoyé par Alice

Ceci étant, le code SSE/SSE2/MMX est bien le même quel que soit le processeur détecté…

Ca impliquerais que les instructions SSE/SSE2 soient traitées de la même façon sur tous les CPU, ce qui n'est pas le cas.

A première vu ça semble être le cas... Le code assembleur semble bien être le même pour AMD et Intel... :heink: A vrai dire, je trouve pas ça aberrant, même si la précision des instructions est différente... :??:

**Neo_13** · 08/08/2005, 09h00

Envoyé par Sam D.

Ca mériterais pas une news ça ? :D

Faut faire un petit soft rapide pour le démontrer et zou.

moi, je pense que c'est une bonne idée... juste pour informer les gens qu'un truc qui s'appelle pareil ne fonctionne pas pareil...

**fefe** · 08/08/2005, 10h50

Honnetement quand tu utilises une fonction ou il y a marque approximation 12 bits de la fonction X dans les specs, cela est-il genant d'avoir le 13 eme bit apres la virgule different entre 2 concurents ?

Perso je pense pas. Cela peut effectivement donner des trucs bizarres si tu fais (if approx(1/x)-a == 0) et que les 2 processeurs prennent un chemin different, mais ca apprendra au prorammeur que l'on ne fait jamais de ==0 en FP mais abs()<=epsilon.

Toutes les personnes qui utilisient des applis critiques evitent ces instructions qui sont surtout la pour normaliser des vertice en graphiques, et la precision dans ce cas est bien assez suffisante pour que tout s'affiche au meme endroit a l'ecran.

**Neo_13** · 08/08/2005, 11h22

je me souviens d'un "jeu" de mon prof de math de spé...

Il s'agit de rompre la foi en les ordinateurs et leurs faculté de calcul numérique :

Il nous a donné une série numérique alternée. On a calculé la convergence de la suite. Je ne me souviens plus de sa convergence, mais un truc genre 0 ou sqrt(2), mais bref, convergent à l'infini, avec une convergence très "sensible" vers n=50 et au dela...

Ensuite, on passe sur PC (Maple, mais n'importe quel logiciel aurait eu le même problème). On code la suite, puis la série. On lui fait calculer la valeur de la série pour n=1e6... histoire d'être sûr. et là, ca a été le drame... divergent... et divergent fort... rebelote à n~500 . Déjà divergent...

Là, j'ai vraiment pris conscience du problème de l'approximation... qui n'était qu'un problème abstrait et sans intérêt pour moi (je concevais aisément le problème pour les trajectoires de planètes, mais pour une simple série alternée dont la convergence est visible "à l'oeil"...)

Le problème d'arrondi est normalisé pour que les erreurs soient les mêmes et donc la reproductibilité soit parfaite, afin de résoudre les problèmes une fois pour toutes. Si la norme n'est pas respectée, ariane 5 peut se retourner et on est obligé de la faire exploser en vol, tout ça parce que le calculateur n'arrondirait pas "comme prévu dans la norme utilisée en simulation". C'est un vrai problème, pas une branlette de geek matheux en mal de bug caché...

**fefe** · 08/08/2005, 11h30

Le phenomene dont tu parles est appele phenomene d'absorbtion.

Quand tu les accumules ensemble un gros nombre FP va absorber un petit au lieu de s'y ajouter et cela par manque de precision (la precision est dynamique en FP vu que tu as un exposant, si les exposants sont trop differents la mantisse de l1 peut valoir 0 du point de vue de l'autre). Si tu ajoutes de la precision tu peux te retrouver dans le cas ou l'absorbtion disparaitra.

L'exemple classique est de faire la somme des 1/x avec x croissant de 1 a n et decroissant de n a 1. En simple precision le phenomene appraraitra tres clairement, bien mois en double et etendue mais tu auras toujours dans un des deux cas une des suite qui diverge et l'autre qui converge alors qu'il s'agit de la meme.

Et cela n'a rien d'un bug. C'est juste intrinseque a la representation des nombres en FP, et accepte par la norme en tant que telle. Cela rappelle souvent durement aux entreprises qui ont des applications critiques que n'importe qui n'est pas a meme d'ecrire du code FP, et que si tu veux etre serieux tu dois faire une analyse de convergence et de precision de tes algorithmes. Je peux te rechercher des exemples de ce type d'errerur, mais les plus connus sont un crash d'Ariane ou des patriots qui rataient leur cibles si ils n'etaient pas rebootes toutes les 24h).

**johnnyholzeisen** · 08/08/2005, 20h47

Ça commence à devenir vachement mathématique

Ce sujet pourrait aussi intéresser JF Maquiné pour Onversity. Enfin, vu comme c'est abordé sur le forum (côté software)

**fofo** · 17/08/2005, 11h30

http://www.clubic.com/actualite-2182...-directx-.html
:x

**lechenejb** · 17/08/2005, 11h45

Envoyé par fofo

http://www.clubic.com/actualite-21829-john-carmack-bientot-developpeur-directx-.html
:x

Qu'est ce que je disais, OpenGL dans les jeux va tendre à disparaitre, souvenez de DOOM 3, c'est certainement le dernier gros moteur OpenGL ...

**Alice** · 17/08/2005, 13h02

Envoyé par John Carmack - id Software

"I'm happy working with D3D9 on the Xbox 360 platform. We did seriously consider going D3D only on the PC, but there are still some mitigating factors. OGL will probably still be slightly higher performance on the PC pre-longhorn. ATI and Nvidia both still like the idea of being able to do more focused optimization work in OGL. We also still care about the Mac and Linux platforms." (http://www.beyond3d.com/forum/showthread.php?t=22498)

Il est fortement sous entendu que son nouveau moteur soit OGL sur PC. Comme toujours, Clubic aime gonfler l'actualité pour lui donner un côté "scoop".

Dans tous les cas, que Carmack utilise D3D se comprends. Les progrets accomplis par Microsoft font de D3D une bonne API. Dans son nouveau renderer, Carmack utilise des Shadow Map et sans aucun doute du HDR ce qui nécessite "un peu beaucoup" des Render Target efficace. Bien qu'OGL2.0 formalise proprement les Render Target (Frame Buffer Object) les drivers ne sont toujours pas au point ce qui est particulièrement énervant (Par exemple, Associé un Stencil à un FBO est toujours folklorique puisque ça ne marche tout simplement pas).

Discussion: [News] OpenGL

Outils de la discussion

Règles de messages