Reprise du message précédent :

uai mais si t'as une carte qui fait les shaders qui est pas full dx9 (enfin arb2) tes shaders tu peux aller te gratter

 
Voilà Desuet, Ecoute notre gourou OpenGL du topic

 
complètement d'accord.
 
c'est vrai que le Cg passe par l'API sous-jacente et ses restrictions, mais c'est d'abord un langage, rien ne l'aurait empêché d'évoluer ensuite via un compilo dans la couche driver.
 
par contre pour le défaut du compilo embarqué dans le driver, c'est pas tellement les défaut que tu cites que je vois, c'est qu'une approche de compilation à la volée qui permet de maximiser le rendement coté GPU, générera plus de charge coté CPU (après c'est au niveau appli de maintenir ce qu'il a déjà fait compiler par le driver).
 
par contre question budget R&D pour le driver intégré au compilo, il faudra un peu de temps pour maitriser l'approche, mais c'est du R&D à long terme.... et puis on est dans le domaine de la high-tech, ceux qui font pas l'effort de suivre temps pis pour eux, on va pas briser l'évolution des API en fonctions de boulays qui font les chose à moitié (ça fait quand même longtemps que l'on sait que du hardware avec des drivers pourris ne sert à rien nVidia a été le premier à le comprendre, Ati a compris, les autres on verra mais je pense qu'ils ont compris aussi, l'époque du 95% dans le hard et 5% dans le soft est révolue je crois)....
 
par contre que l'on passe par un HLSL intégré au niveau driver, ou au niveau API (dans une libraire statique liée à l'éxécutable), si le hardware ne supporte pas les fonctions utilisés dans les deux cas ça passe pas.... (donc que ce soit au niveau DRIVER ou au niveau API, on peut se retrouver avec un shader de fallback à faire....)
 
par contre j'ai hate de voir si dans le futur avec un compilo au niveau driver, on pourra controller dans un moteur comme Doom 3, des define ou des options d'optimisations qui seront passés au driver via la console   (connaissant carmack il se fera un plaisir de le faire )

 
Comme ?

GF3 GF4 Xabre (il me semble) 8500, si pour les GF et ati t'as une optimisation specifique ce sera surement pas le cas des modeles moins vendu

 
Alors  
GF3/GF4->code path NV20.
8500->code path R200.
Xabre->aucune idée mais d'après les extensions supportées je dirais que ça passera par le code path ARB.
 
Dans tous les cas tu auras les mêmes effets, seule la version ARB2 dispose d'une qualité d'image légèrement supèrieure vu que Carmack s'est amusée avec, mais ça restera en grande majorité indécelable.

 
vi, mais ayant fait des essais avec l'alpha, sans chercher à avoir énormément de précision par canal, passer du S3TC au 32bpp pour les textures c'est mieux pour le bump (mé bon ça fait plus mal au framerate )

oui mais tu tirera pas partie des instructions que le Xabre fait (shader), encore que la c pas un bon exemple vu ke doom3 n'utilisera pas les shader (si g tout bien lu)

non c'est pas ça.
 
un shader c'est une approche de description des opérations à faire sur tes pixos/vertex.... (avant c'était un système d'états).
 
un shader permet d'assouplir la création des effets que tu veux faire.
 
Doom 3 avec ou sans "shader" pourra avoir presque le même rendu, mais plus la carte est évoluée (plus le support des shader est important) plus le rendement est élevé.
 
(a tort on a assimilié les effets comme le bump par Dot3 et l'Environmental Bump Mapping aux pixel shaders, souvent utilisé pour les effets d'eau et de déformation optique)

 
Pour le Cg disons que ce n'était pas dans sa "philosophie" de se mêler au driver vu qu'il voulait rester au dessus de l'API afin d'être portable au maximum. D'ailleurs s'il était intégré au driver comment lui passerait on le code ? il faudrait des points d'entrée vers le compilateur Cg dans les API. Et comme HLSL et Cg sont finalement le même langage autant intégrer directement HLSL au niveau du drvier. D'ailleurs nVidia était un des plus farouches opposants au sein de l'ARB à l'idée d'intégrer le compilateur dans le driver.
 
Pour la compilation à la volée ça ne devrait pas trop poser de problèmes après tout DirectX 9 permet déjà la même chose même si le compilateur au lieu d'être dans le driver est dans une bibliothèque (D3DX).

 
Les normal maps se compressent mal effectivement, le S3TC a pas été prêvu pour ça...

 
et vi c'est vrai.... (donc du coup y'a pas vraiment de contre indication à intégré le compilo dans le driver, hormis beaucoup de boulot intial pour les dev du driver)

C'est p'têt que je suis de la vielle école (j'ai fait pas mal d'info embarquée), mais pour moi compilo et driver, c'est 2 choses très différentes.
 
Quand on développe un jeux (et on le développe pas encore en JAVA), y a un compilo qui traduit le langage de haut niveau en code assembleur une bonne fois pour toute, donc pourquoi ne pas faire la compilation du code d'appel graphique (que l'on a dans le SDK de directX) en même temps ?
 
Sûr que la compilo à la volée est une solution qui pourrait être adoptée à l'avenir, mais pas avec l'architecture actuelle des GPU (faudrait que l'architecture d'une CG se rapproche de celui d'un ordinateur).
 
(un HLSL en .NET, quelle horreur )

tiens cette allusion à .net fait ke je me demande ce que ca donnerait un langage de shaders objet (j aime). La question est plutot est ce que ca vaut la peine de se fatiguer à créer un tel langage pour cette tâche là (paske pour le coup, créer un compilo de langage objet là c est qd mme plus de boulot k un simili C)

 
Avec une modélisation UML en plus !!
 
Pourquoi utiliser un bazooka quand une tapette à mouche suffit..

La question est : est-ce utile les concepts objets pour ce genre de  programmation ?
 
Je repondrais pas je sais pas comment ca se programme les shaders

 
- Pour avoir regardé du "code" shader qui sont dans la version 2 des instructions plutôt spécialisées... euh... du genre opération mathématiko-graphique (là je résume )
 
- De plus en ce moment, les objets manipulés sont assez simples (vertex et pixel (on peut avoir une discussion intéressante sur le niveau d'atomicité des objets à manipuler ))
 
Ma réponse est: NON

oui c est exactement ce que je dis ds la seconde partie de mon post, je suis tout à fait pour l utilisation d outils adaptés (donc si j ai pas besoin du bazooka, tant mieux).
 
mais bon, un objet pixel, vertex, polygone, texture... non ca vous dit pas ? (bon et des structures, on peut ?)

 
Pourquoi pas !!
 
Mais dans ce cas, la réutilisabilité, l'héritage, le polymorphisme, les fonctions virtuelles, etc... enfin, tout les concepts de la programmation orientée objet, t'en fais quoi ???
 
Si on a que des relations d'appartenance (ce qui serait plutôt le cas), la structure est adaptée...
 
(P.S. pour moi même -> t'es plus au boulô mon gars )

l'objet pour des shaders, bof....
rien à construire, rien à détruire...
 
par contre supporter les templates why not....

 
OUI, mais dans le cas au tu fais de la prog pour de l'embarqué, tu connais ton cpu cible, et exactement ses caractéristiques (tu as certainement utilisé du 68K ou du PowerPC avec CodeWarrior non ?)
 
dans le cas des cartes 3D, le hardware est variable, et change tous les ans ou deux ans...
 
dans le contexte des CPUs, l'architecture interne change tous les 4 ans (regarde la longévité de l'archi du Pentium Pro qui a donné le P2 puis le P3, depuis combiens de temps on a l'Athlon, le P4 aussi, et depuis combiens de temps le PowerPC existe (depuis le Pentium 1), bien qu'il ait évolué aussi).

 
Mouais des templates... bof bof
 
Si on part dans l'optique jeux, si tu définies un template, c'est que tu vas le réutiliser, donc tu va te retrouver avec le même résultat pour des jeux différents (merci l'uniformisation).
 
Ou alors ça devient des templates paramétrables, et là, on est pas sortie de l'auberge....

Vu à l'instant sur nvchips-fr.com...
 

 
Citation du site :
Ces résultats auraient été obtenus avec le code patch DirectX 9 pour la carte ATI et le code path NV3X pour la carte NVIDIA, dans la résolution 1024x768 sans antialiasing ni filtrage anisotripque.
 
...

un template c'est en tant qu'outil dans le langage, je parles pas de template déjà fourni....
 
de toutes façon, les manières de calculer les éclairages & autres trucs sont connus, et contrairement à ce que tu pense, y'a beaucoup plus de choses qui sont les mêmes dans les jeux actuels et passés, alors que tu as ptet l'impression qu'il y a énormément de diversité (créé par le coté artistique).

 
le programme compilé (le jeu) attaque les fonctions d'entrée du driver, jamais le GPU.
 
On divise la complexité en plusieurs parties...
 
- De la fonction d'entrée du driver vers le microcode du GPU => donc au fabricant de fournir l'adaptation API vers matériel (driver ATI, nVidia, Matrox,....).
 
- Du compilo vers les fonctions d'appels (doivent être "normalisées" dans directX) => c'est l'éditeur du compilo qui doit développer un moteur de traduction langage évolué vers API (les visuals de MS, les builders de borland, etc...)
 
- Enfin dans le jeu lui même, avec les développeurs qui doivent traduire une spécification fonctionelle en algo informatique.
 
En général, ce qui arrive dans le cadre d'un développement de projet "normal", c'est uniquement spécif -> code source programme. Tout ça reste indépendant du matériel.
 
On peut bien entendu utiliser d'autres solutions (comme celle du HLSL compilé à la volée qui concentre deux complexité en une seule). Question de coût...

on est d'accord et pas d'accord, alors histoire de savoir comment tu vois le truc:
 
on est d'accord que ton jeu/appli est compilé pour ton PC (donc un Athlon/P3/P4.....). ouki.
 
les shaders sont programmés en langage de haut-niveau simili C. (dans le cas du directx8 on avait que de l'asm).
 
y'a deux solutions pour la compilation de ce truc: soit le faire compiler par l'API qui n'a pas la connaissance du hardware du gpu et que se base sur un jeu d'instruction défini, soit le faire par le driver qui a la connaissance du hardware du gpu et qui n'aucunes restriction de jeu d'instruction ou de standard.
 
(edit: j'ai eu du malle)

je sais pas si tu as bien suivi le truc, mais le shader que tu va faire compiler, ça donne en lui même une séquence de code/µcode qui sera éxécuté par le gpu lui-même en temps qu'unité autonome...
 
en fait on est ptet d'accord

en fait tu as l'air de faire la projection des MFC/VCL par rapport aux API Win32/GUI au niveau des cartes 3D, ce qui est complètement inadapté et faux....

j'suis vieux donc je prendrais la 1ère solution à cela près que:
 
API = application programmation interface => donc c'est un ensemble de description de point d'entrée, pour le driver (autrement dit une API ne compile pas)
 
C'est le compilo qui compile tout (quitte à rajouter un module de compilation à chaque nouvelle API "normalisée" de microsoft).
 
De plus, je préfère que ça soit un seul organisme (ici microsoft) qui impose un standard/définie une norme plutôt qu'un fabricant (après avoir participé à la mise en norme ISO du fieldbus FIP ).
 
M'enfin, là, on fait la chasse aux neutrons , d'toute façon, c'est le plus fort qu'a toujours raison

 
p'têt bin...

 
justement, dans le cas des GPU programmable, l'API relativement idéale c'est celle qui permette de passer ton shader en C à un compilateur optimiseur intégré au pilote du matériel.
 
on est plus dans le domaine des cartes son blaster 16 ou d'une carte vidéo S3, là il faut te dire que programmer une radeon ou une geforce fx, c'est comme si tu fournissais du code à un powerpc ou a un itanium via un cpu x86 comme cpu hôte, et que quand tu codes ton appli, tu ne sais PAS sur quoi tu va tomber....

Tain, les gars, on est passé d'une interview faussement interessante a des posts techniques et interessant, ca va pas
 
 
 
 

en prenant la chose dans un autre sens:
 
quand tu fais émuler du code x86 par un autre cpu (ppc,itanium,68k), le rendement est médiocre. pourquoi: parceque le code généré correspond pas au cpu qui l'éxécute et on doit faire une émulation (logicielle ou matérielle).
 
dans le cas actuel du HLSL du Dx9, on compile le code C vers une machine virtuelle définie par microsoft et ses partenaires.
 
forcément si le matériel ne correspond plus à la machine virtuelle (soit dès le début, soit au bout d'un an un gpu sort qui est ptet pas nativement compatible), le pilote doit remouliner le code déjà généré pour le nouveau hardware.
 
alors que si tu prends le code en pseudo C, le driver compilant directement le code C en code gpu, le rendement est maximal. (comme reprendre le code C/C++ d'une appli et la recompiler pour un PowerPC ou un Itanium, au lieu de retraduire le code x86 généré à partir du C/C++).

 
Edité car j'ai ecrit des conneries
 
Tout à fait Thierry. J'en deduis donc que le GPU doit posseder des fonctions d'upload de programme (là, on arrive à une CG du genre automate programmable).
 
Avec ton compilo de driver, on tombe dans la complexité de la vérification des expressions régulières (et autres limitations de dimension), et on se retrouve avec des drivers qui vont devenir très très lourds. Le compilo de dev ne pourra pas faire les vérifs car générique.
 
On remplace la machine virtuelle de DirectX par du texte source C ? (perso, ça me choque).

Ce n'est pas que votre discution ne m'interesse pas ( bien au contraire j'apprend plein de chose ) mais je me demandais juste si l'un de vous avait deposé une glyphe de garde anti-troll a l'entrée du topic parce qu'on ne voit plus l'autre vandamme de l'info, pas qu'il me manque mais bon il est peut etre mort, faudrait s'inquieter non ??!!  
 
Allez y continuez faites comme si je n'etait pas la...    

 
C'est vrai pour un interprèteur mais qu'en est-il des recompilateur dynamique ?  

à quel moment se ferait la compilation proprement dite ? (à chaque exécution du jeu, une fois pour toute ? pas à chaque fois qu un nouveau shader est utilisé qd meme ?)
 
et puis bon finalement les shaders sont apparemment des petits progs assez simples et pas mal limités (au nombre d instructions, nb de registres, adressage, ke sais je encore), donc un compilateur pour ce genre de truc devrait pas etre si énorme que ca non ? quoi que s il doit etre tres malin pour mettre les instructions ds l ordre et bidouiller pour optimiser, ca doit pas etre si évident (et pas si rapide).
 
je pense k on peut deja trouver des macros ds ce genre de langage, apres on va passer aux librairies de fonctions etc... ca va en faire du boulot pour un pauvre driver deja bien occupé (d ou retour à ma 1ere question, qd est ce que le driver trouve le tps de compiler du bazard sans pertes de perfs, à chaque changement de scene ?)
 
tout ca me fait dire que je devrais en lire un peu plus là dessus, paske je dois dire bcp de conneries et poser des kestions idiotes.

Trés interessant topic, mais il y a une chose que je ne saisis pas.Imaginant que la Radeon 9800 et la GF FX5900 ont la même rapidité dans HL2, est ce que la qualité de la GF FX sera  la même que la 9800? Car si je me rappele bien Nvidia avait bien parlé de la qualité graphique supérieur du GF FX alors que  jusqu 'à présent il n'en est rien.

La qualite est superieure quand on utilise une precision de 32 bits pour les shaders. Or, c'est tres lent dans ce mode. De plus, les specs DX 9 se base sur du 24 bits (au minimum), ce que fait le 9800 mais pas la 5900 (c'est soit du 16, soit du 32).
 
Donc en gros, si on respecte a la lettre DX 9, on tourne en 24 bits sur la 9800 et ca marche bien et en 32 bits sur la FX et ca marche moins bien
 
Edit: merci a Mareek pour les precisions    

 
pourquoi tu parles d interpréteur ? ca m étonnerait que BJOne pense à ca (et y a rien de spécial qui m y fait penser ds ses propos)
 
sinon ca serait vraiment étrange d incorporer un interpréteur ds un driver, niveau performance ca me semble pas terrible comme solution, interpréter le shader pour chaque pixel... bonjour le travail en +

 
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: