Reprise du message précédent :

 
Pour l'interpreteur, je pense que tu parles de: machine virtuelle vers appel de l'opcode machine...
 
Les recompilateurs dynamiques de C vers opcode (c'est des JIT dont tu parles ?), faudra attendre une nouvelle version de DirectX (c.a.d virer le langage intermédiaire pour du "banal" transfert de code source vers le driver). M'est avis que c pas pour demain...
 
Si c'est du recompilateur dynamique de langage intermédiaire vers opcode, là, ça peut arriver beaucoup plus vite (a condition que l'architecture de la CG s'y prete = sauvegarde de contexte)
 
Dans c 2 cas c quelques millions en R&D pour les constructeurs pour refaire de nouveaux drivers...:whistle:

 
apparemment la solution préconnisée par nvidia est de choisir la bonne précision au bon moment pour avoir perfs et qualité à la fois (amis de l analyse numérique, on a besoin de vous). pas évident tout ca.

 
Nan c'est parcequ'il parlait d'émulation.

Enfin il a fait une démonstration comparant l'emulation et les shader.

Donc Ernestor, si j 'ai bien compris , la Radeon 9800 aura  une meilleur qualité graphique car une precision de 32 bits pour les shaders est trés lente et ne sera donc pas utilisée. Donc si on régle la qualité graphique dans les option du driver de la Radeon au niveau de la GF FX la Radeon sera plus Rapide?

Juste une question qui m'interpelle en tant que programmeur...
Si le compilo est integré au driver, ça suppose que le programme (le jeu, la démo etc.) ne sera pas présent en tant qu'éxécutable binaire mais en tant que code source.
Donc ce qui me chagrine c'est d'imaginer les codes sources se balladant comme ça... m'est avis que les développeurs de jeux ne seront pas chauds...
donc si j'ai bien compris ça sera un mélange de binaire compilé au préalable qui tournera sur une API (directx etc.) plus du code source compilé à la volée pour les parties qui seront spécifiques au hard. c'est ça? j'ai bon?

Non c'est pas tout a fait ca
 
La FX fait du 16 bits (moins beau mais rapide) ou du 32 bits (tres beau mais lent). La 9800 fait du 24 bits (beau et ca tourne bien).
 
Un jeu qui suit les specs DX 9 va - en general - se baser sur des shaders en 24 bis. Donc c'est nickel pour la 9800. Par contre, ca l'est pas pour la FX ou il faudra choisir entre du 16 ou du 32

attention, mélangons pas tout:
 
le code de l'appli/jeu est compilé (en x86) comme d'hab ça change.
 
la seule chose qui est compilé par le driver sont les shaders en HLSL. (dans le cas de l'OpenGl 2.0).
 
évidemment, comme il faut éviter de recompiler dans tous les sens, le moteur 3D du jeu devra maintenir la liste des derniers shaders compilés.

donc pour comprendre justement comment c foutu au niveau API, vous pouvez zieuter les white papers de l'opengl 2.0 chez 3dslabs...
 
http://www.3dlabs.com/support/deve [...] /index.htm
 
sachant que le directx devrait converger aussi vers le compilo HLSL déporté en tout ou partie dans le driver....

 
A priori ça bouffe énormément de temps, et ça ne profite qu'aux nV35 (et peut-être nV36/38). Les nV30, 31 et 34 n'ont quasi pas de gain en jonglant. Les développeurs trouvent cela inutile, harrassant, non rentable, etc.
 
En gros, codepathier les jeux pour les FX parce qu'elles ne suivent pas le standard est un désavantage.

 
(1)
une fois pour toute = faudrait une architecture qui existe pas aujourd'hui avec un compilteur qui soit capable de générer du code pour toute les CG.
 
A chaque execution du jeu:
- à chaque "commande graphique" (même si c'est la même) = interpréteur (perte de contexte)
- compilation la 1ère fois que le programme rencontre la "commande graphique", appel les fois suivantes  = compilateur Just In Time (JIT), le contexte est sauvegardé quelque part.
 
(2)  
J'ai donné des cours sur le langage GRAFCET (langage de complexité  équivalente à celle des shaders actuellement, pour la programmation d'automate progrmmable industriel), et j'en ai retenu que:
 
La plupart des erreurs sémantiques peuvent être éliminées à l'écriture du programme. Processus de vérification effectué par un logiciel de taille "conséquente" (au niveau de la console de programmation, pas question de les faire vérifier par l'automate).
 
En effet, la généricité est très mal gérée par le coté matériel (ou les drivers) car cela revient à devoir prendre en compte tout les cas de figure.
 
A contrario, ce n'est pas impossible, à condition de bénéficier de ressources importante (G/CPU, mémoire).

Ernestor peus tu m'expliquer un peut plus en détail car je pense qu'il ya un truque de louche. Si la Radeon travaille ne 24 bit et la GF FX en 16bit donc la qualité de la Radeon est meilleur, par contre la GF FX n'est pas plus rapide , à moin que je me trompe?

Oui, c'est vrai sauf que quand la FX est en 32 bits, c'est plus joli que le 24 bits de la 9800

Mais est ce que c'est jouable avec une GF FX 5900 en 32bit? Moi je pense pas?

en fait on pourrait presque vivre avec le compilo "statique", mais faudrait au niveau driver réorganiser le flux....
 
donc c'est très probable que l'on évolues vers l'approche retenu par 3dlabs (donc passer directement le code source C du shader au driver pour qu'il le compile)

 
A cause d'une limitation de l'architecture interne des nV3x, le mode 32bits est "lent" .

le compilateur HLSL ne sera pas intégré aux drivers
parce que Microsoft ne veut pas ecrire de test WHQL qui testeront les drivers sur ce point. Il veut garder le controle sur HLSL.
 
Ceci dit le code assembleur transite en clair entre l'API et le driver (ou entre l'appli et l'api) donc ce n'est pas un probleme de securité mais plutot une décision politique de Microsoft.
 
Bien entendu, il y a deja un compilateur intégré aux drivers: celui qui traduit le langage intermédiaire de Dx (un peu comme java ou MSIL) en opcodes comprehensibles par le hardware.
 
De plus dans pas longtemps il y aura dans les drivers OpenGL un compilateur complet GLSLang.
 
LeGreg

Mais est-ce aussi visible que entre 16 et 24? la est la question...

BJOne dit que :

 
et les shaders, on les garde ou ? un cache pour garder les shaders les + utilisés/derniers utilisés ?
 
 
The paladin nous dit que :

 
je voulais dire une fois pour toute à config donnée bien sûr.
 

 
l interpréteur, je suis contre (j en ai déjà fait un, c est rigolo mais ca me semble pas intéressant au niveau perfs), pour le JIT, je connais pas (ou alors j ai manqué un cours ou deux) mais il me semble que ca amenne un pb : qd on rencontre un shader pour la 1ere fois, hop on compile, poum ca rame.
 
là je nage en pleine science fiction, mais est ce qu on verra ds le cas du compilo intégré au driver une phase de compilation des shaders avant l affichage de la scene ? (l utilisateur préfère attendre une bonne fois et plus etre emmerdé ensuite)
 

 
là je sais pas si les vérifs sémantiques sont tres complexes, a priori y a peu de types de données, le langage reste simple ... à mon avis (je dis sans doute n imp) y a pas grd chose à faire de ce coté là... et puis on voit bien si ca passe à l exécution... (solution caca)  
 
ca me rappelle des souvenirs de cours tout ca... faudrait ke je m y remette, mais en attendant hop au dodo.

Je sais pas precisement

 
D'accord dans les grandes lignes.
 
Le compilo HLSL -> opcode, je le vois plutôt comme un traducteur d'une instruction "évoluée" HLSL, vers 1 à n opcodes de GPU, que comme un compilo "émulateur".
Je pense pas qu'il doit y avoir de fonctions complexes de transformation/vérification de HLSL vers opcode, on reste quand même dans un monde "délimité" (faute de trouver de terme plus adéquat ).
 
GLSLang c'est le nom du langage de programmation haut niveau en environnement OpenGL ? (j'ai la flême de googleliser )

 
Difficile à mettre en oeuvre, vu que le code graphique est perdu au sein du code "jeu", ça voudrait dire qu'il faudrait un moteur de recherche de ce code au sein du code entier de l'appli pour qu'il puisse le compiler une bonne fois pour toute, par exemple à l'amorçage du programme, ou à l'entrée d'un module applicatif.
 
Le JIT, c'est compiler l'instruction "en langage évolué/intermédiaire" en opcode, la première fois que la machine d'exécution (hum, hum, le terme est pas très bon) rencontre l'instruction, les fois prochaines ou l'instruction sera rencontrée , il n'y aura plus de compilation mais exécution des opcodes qui avait dû être stockés quelque part (d'où la necessité de sauvegarde de contexte).
 
=> La première fois qu'une instruction est rencontrée, son exécution prend plus de temps que les fois suivantes (et c'est là où pour l'utilisateur, peut y avoir un petit délai d'attente).
 
Bon dodo

ben justement, je ne crois pas

 
que ce soit de l'asm Dx8, ou du HLSL Dx9 ou du GLSlang OpenGl 2.0, c'est au choix de l'appli: soit elle fait l'assemblage ou la compilation à la demande, soit elle fait une précompilation par anticipation avant d'entrer dans la partie temps réel (au chargement du jeu/changement de niveau, etc....)
mais ça à l'appli de le décider l'API ne peut pas le faire pour elle.
 
ça veux aussi dire que lorsque qu'un HLSL est utilisé (ou même l'assembleur DirectX 8 brut de fonderie), le code source du shader est en clair dans les fichiers de ressource du jeu (alors après si les fichiers sont compressés dans un format maison ou dans un format connu mais modifié, tu les verras pas facilement).
 
donc, d'un coté l'ancienne approche par "machine d'état", permettait aux programmeurs du moteur de planquer un peu leur astuces....
 
alors que le HLSL laisse trainer les sources des shaders à qui veulent les pomper (enfin d'un coté même si un shader sympa c'est cool, le plus gros du boulot est dans le moteur 3d qui est compilé donc plus dificilement reverse-engineering-able )

 
en espérant qu'ils changent d'avis avec le temps....
de toutes façon si l'OpenGl 2.0 se montre comme une réussite technique dans la pratique, ça les fera bouger...

http://www.presence-pc.com/news/n1720.html
 
Que pensez vous de cette news ?
Je trouve ça un peu gros quand même  

 
enorme ...
remarke ils aurais sortit le jeu a temps, les gars aurait ete occuper a autre chose

au debut j'y croyais pas, mais si presence-pc dit qu'ils ont été chopés l'archive, c'est que c'est vrai (je compte sur eux pour pas avoir mythonné) à priori c'est pas cool, ça ne remet pas en cause le succès commercial d'Half-Life 2 à venir, mais ça risque de sacrément décaler sa sortie:  
 
ptet que le jeu était gold est prêt pour la duplication, mais là ça peut retarder la sortie d'un mois au deux car ils vont devoir changer tout le système d'authentification sur steam et de numéro de série (parceque si le code d'authentification au niveau des serveurs steam a leaké avec, on devrait pourvoir faire des keygens pour au moins half-life 1 + counter qui marcheront sur le net).
 
il serait interressant pour savoir si ce qui a leaké c'est half-life 1 + steam (la version actuelle), par contre si y'a tout le moteur d'half-life 2, ça pourrait reduire la quantitée de licenses du moteur, car au lieu d'acheter une license pour batir un jeu sur HL2, des équipes de dev vont pouvoir plagier le moteur.
 
d'un autre coté pour les apprentis dev de moteur 3D, ça peut être une source de formation

 
Qui se traduira par un paquet de jeux de qualite que pourront sortir les boites ne possedant pas des millions de dollars d'avance pour le paiement des licences.
 
Bref c'est tres con pour eux, mais ça peut au final etre tres avantageux pour les utilisateurs finaux de ce type de jeu.
 

 
ben s ils ont un vrai systeme d authentification (clés privées / publiques, certificats etc, un truc sérieux quoi) ca devrait pas trop poser de pb de ce coté là (c est pas parcequ on connait les algos que c est facile à craker, cf pgp par exemple), mais si c est une bidouille à 2 balles alors oui , c est la merde.
 
BJOne dit :

 
ok, ca parait logique (et c est bien d avoir le choix)

 
On devrait te couronner du titre de "Nicolas B. d'ATI"
tellement ta perseverance est touchante..
 
LeGreg

arf vous avez fait fuir nicolas. ;(
On s'amusait bien pourtant avec lui.
 
Pour rappel notre expert donnerait sa main à couper que le tnt2 est t&l en hard

 
Encore mieux, monsieur était persuadé que la TnT2 était la 1ère carte à faire du H&L (ce qui donne une bonne indication sur son niveau de connaissances techniques).

 
pour revenir sur cette histoire de précision, hypothese à la con :
ca veut dire qu en programmant son shader pour fx (en utilisant le cg par exemple) on doit réfléchir si on a besoin d une précision simple ou double c est ca ? en gros préciser le type du flottant ?
si oui c est ce ke tout programmeur un peu rigoureux fait, et ce avec n importe quel langage non ?
 
c est qd meme pas la mort (meme si effectivement c est moins simple).
 
apres il y a la difficulté d optimiser le code pour que toutes les unités de calcul du gpu soient alimentées et avoir un rendement maximum, mais un compilo suffisemment malin devrait s en sortir (réorganisation des instructions etc)... donc aura t on mieux sur les fx avec de futures versions du compilo fournit avec le cg ?
 
si je demande ca c est par curiosité technique paske bon je fais pas de prog graphique et j ai pas de fx

sur les FX, c'est le probleme des registres, qui sont en nombre insufisant. Le passage en FP16 permet d'acceder a 2x+ de registres.

 
Encore, l'erreur est humaine, il pouvait se tromper sur son premier post, mais le pire, c'est qu'il a soutenu cela pendant 4 pages    
 
 

 
ben par exemple on peut imaginer qu on a pas tjrs besoin d un grd nbre de registres et k à certains moments du code passer en fp32 est moins handicapant k à d autres, alors là soit c est le programmeur qui se prend la tête, soit c est le compilo ki prend des initiatives (j aime pas ca, parce que j imagine que qd tu tiens à avoir du fp32 sur des opérations demandant bcp de précision et ke le compilo passe derriere sans rien te demander...ca doit etre énervant)
 
sinon en plus il y avait en plus du pb des registres le fait que certaines des unités de calcul du fx passaient leur temps à rien faire (ou un truc ds le genre) et k il fallait bien optimiser pour y remédier (prise de tete assurée)

 
Legreg, ça serait quand même utile que tu admette que codepather pour seulement les nV35/36/38 (les autres n'en tirant que peu d'avantage) en bouffant énormément de temps de développement, c'est pas super top pour le développeur. Après, c'est sûr qe pour l'utilisateur final qui a ces cartes c'est mieux. Mais je suis certain que le développeur serait heureux de pas avoir à faire 46 profils différents parce que  une catégorie de chips a du mal à ingurgiter les trucs qu'on lui demande alors qu'il est estampillé pour. C'est très peu technicisé ce que je dis, certes, mais c'est pourtant du bon sens, non ? Enfin, je me trompe peut-être... Mais à ce que j'ai compris, ça enquiquine plus les développeurs que ça ne les réjoui de devoir écrire des trucs spécifiques à certaines FX pour essayer de les sauver....  
 
Enfin, c'est ce qui transparaît de certaines interventions de développeurs, notamment après la présentation de Valveil y a quelques temps... Tous les développeurs n'ont peut-être pas le temps ni l'argent de prendre soin d'un parc réduit de cartes.....
 
Je pense que si Gabe Newell a dit que cela aurait plus valut le coup de faire purement et simplement tourner les FX en DX 8.1 au lieu de se taper un codepath spécifique, ça n'est pas QUE marketting.
 
Après, chacun en pense ce qu'il en veut.
 
Au fait, tu me trouve touchant ? C'est cool, parce que je trouve ta condescendance plus que touchante

T'en a pas plutot rien a battre?

Ce qui me fait marrer c'est ça : "Vers le 11 septembre de cette année...", alors est-ce que c'est le 11 septembre précisément dans ce cas le hacker a un sens de l'ironie certain, soit c'est Gabe Newell qui est marqué (comme la pluspart des ricains) par cette date et pour lui une tragédie ne peut se produire que ce jour là.
 
Ou bien c'est une pure coïncidence...

 
Si bien sûr