Reprise du message précédent :

petites remarques au passage:
-DirectX est une API
-Rendermonkey est un IDE (outil de developpement)
-Cg est un langage de programmation (enfin pas tout à fait)  
 
beau mélange de la part de nicolas_b

Et toujours dans le meme paragraphe, encore une aberration a propos d'une API qui va au detriment de la portabilite.
 
Pas de bol, une API ca augmente au contraire la portabilite

ça dépends de ce qu'on entends par "portabilité".
DirectX favorise la portabilité entre les différents hardware, pas entre les OS

Certes
 
Mais globalement une API est utile pour s'adapter a "differents contextes". Par contexte, apres on entend ce qui va bien. Et la, il me semble qu'on est dans un debat sur DX 9 donc le contexte c'est la gestion des differents hardware (nVidia ou ATI) sous Windows. Donc j'ai bon    

 
j'ai pas le lien, mais tu oublies aussi le topic ou il affirme que les geforce3 sont potentiellement capable d'abattre ma 9700 pro les yeux fermés et les pipelines dans le dos ...

 
désolé    

spas lui

Le plus enorme chez Nicolas_b, c'est quand meme ca :
 

 
ah oui, maintenant que tu le dis..
 
mais c'etait un trolleur du meme acabit qui est apparu le meme jour.. d'ou ma confusion

non, l'adorateur de la GF3 était un minable, nicolas_b est un dieu

 
  ENORME !  

 
  monstrueux  

 
de la pure propagande... nvidia et dx9 -> poubelle

http://www.notforidiots.com/ATIDR
 
Un lien INtéressant.........
 
document interne à ATI et Get In The Game (développeurs associés).
 
C'est très PR-isé, mais très loin du FUD à la nVIDIA.... On peut tout voir comme réaliste, avec un petit côté en faveur d'ATI, bien entendu. Mais bon, c'est une présentation interne.... reste qu'ils touchent pas mal de point sensibles

 
Sauvegarde sur ton disque et retourne les slides, ça vaut mieux, parce que sinon, ut auras un bi torticoli et un droiticoli.

j'ai commencé à lire et je me suis pris un torticolis, c'est normal ?

Purée, mais c'est gnéial ça ! Réponse rapide !

j'ai que ça à faire

Le con, il m'a bouffé mon post !

test
Cool, les signatures marchent

nicolas beytout ?

bon va falloir se calmer les gars, j'ai pas tout lu, mais quelques remarques de nicolas ne sont pas fausse à savoir:
(en fait il est braqué et un peu tout le monde, ptet l'air du forum   )
 
effectivement, passer par un compilateur générique est pas top d'un point de vue performances:
 
la solution GlSlang proposée par 3DLabs (avec le soutiens d'Ati ou passage), où le compilateur du langage de haut niveau est intégré au driver OpenGl 2.0 est philosophiquement supérieure à ce qu'offre actuellement Direct3D 9.  
 
à l'heure actuelle il faut reconnaitre qu'avec Direct3D en HLSL, on pourrait presque dire qu'on compare un Athlon avec un P4 via du code optimisé pour les pipelines d'un Cyrix. (c'est très très éxagéré, mais dans 2 ans, si on ne déplaçe pas le compilo dans le driver, ce sera ça)
 
il faut bien comprendre, que ce soit un CPU, ou un GPU/VPU programmable, à "même jeu d'instruction" deux CPU ou GPU auront un flux d'instruction idéal propre. d'où le problème philiosophique avec le compilo au niveau API et non au niveau DRIVER.
 
ok, le directx est ce qu'il est, mais il est là.
 
il va y avoir un peu de boulot pour stabiliser l'approche où le compilo est dans le driver, mais même si l'OpenGl 2.0 qui veut rendre la chose possible est le premier à vouloir le faire, les versions de DirectX se suivant à un rythme effréné, je pense que l'OpenGl 2.0 et un potentiel DirectX 10 dont le compilo serait reporté vers le driver seront opérationnels dans le même temps.
 
il est vrai que les radeons 9700+ collent plus aux specs de DirectX, et donc souffrent moins de perte de rendement que les Geforce Fx.
 
pour parler de l'épopée 3DMark2003: (petit ajout personnel dans le contexte du compilo HLSL dans la couche API et non driver)
 
accessoirement, il faut reconnaitre qu'il peut être tolérable -temporairement-, de remplaçer les shaders compilé par le compilo du Direct3D par des shaders optimisés maison (dumoment qu'algorithmiquement c'est la même chose, mais que le flux d'instruction est juste ré-organisé), même si je suis comme tout le monde j'aime pas quand les fabricants grugent.
 
après au lieu de faire un bête remplaçement, nVidia auraient dû implémenter une sorte d'étape de réorganisation de flux d'instruction dans le driver ( un peu à la mode du moteur Out Of Order du Pentium Pro, mais logiciel ). mais c'est vrai que c'est plus long que de faire un remplaçement de code direct
(Et si ils avaient pas rajoutés d'autres conneries, et annoncé tout de suite le problème et comment ils avaient compensés, ils seraient moins passés pour des cons)
 
valà désolé si j'ai dit une grosse connerite....
 
en final: rome ne s'est pas fait en un jour, et tout le monde fait ce qu'il peut
 
EDIT: c'est vrai que son premier post est assez trollesque  

J'ai l'impression que Nvidia est un peut faché avec directX  depuis la Geforce 3   . En fait la Geforce3 est une carte directX 8.0 et même si la Geforce4 Ti est plus rapide elle est aussi directX 8.0 et en gros la GF4 Ti est une GF3 avec des frequences plus élevées . Nvidia n'a jamais fabriqué de carte directX 8.1 et je pense qu'elle a simplement accumulé un retard par rapport à ATI en vers l' implementation de directX.
Par contre même si les nouvelles GF FX ont du potentiel , les producteurs de jeux sont libre d'optimiser ou pas les jeux , et alors dans un jeu qui n'est pas optimisé si les ATI marchent mieux,  donc les catres graphique ATI sont meilleurs. Imaginez simplement si sur le marcher il y avait 10 différante carte graphique avec differante technologie, par exemple valve devrait optimiser HL2 pour 10 technologie , c'est un travail cosiderable et personne ne le ferait. C'est pour celà qu'il faut un standart et actuelement c'est directX.
 

 
quand tu fais "man gcc" tu vois que tu peux choisir avec ou sans ANSI...
mais sans euh ... à part dans de très très vieux bouquins ça fait un bail que je n'ai pas vu du C pas ANSI
par contre le AINSI j'attends toujours de découvrir, faudrait demander à Kernighan et Richie de nous faire un bouquin dessus lol  

nicolas_b a écrit alors que j'étais déconnecté    :

 
oh oui, oh oooui, oh ouiiiiiiiiiiiii  
 

je tiens à remarquer que meme si nicolas_b trolle, quoiqu'il en soit je l'ai jamais vu etre agressif, il a tjs été poli contrairement à certains. Meme s'il a faux, j'aime bien la facon dt il argumente, on a l'impression qu'il trolle juste pour embeter et d'amener de l'ambiance

le probleme est qu'il utilise systématiquement cette technique de troll sur tous les topics ou il passe
 
pas mal le système de réponse rapide  

Encore faudrait-*il qu'il ne FUD pas autant dans ses arguments..... Finalement, al comparaison avec Vandamme est justifiée......... Moi aussi je peux parler comme, lui suffit que je me ramèène dans une discussion sur, allez, le tricot, et puis voilà, hein.... Spa bien compliqué. Y'a un site qui s'appelle la décharge... Y'a des jours je me demande si il n'a pas suivi leur mode d'emploi du troll....
 
http://www.rtfm.be/decharge/pages/flame.htm

 
Pour se retrouver avec un compilateur type JIT (Just In Time), Bof... l'utilisation d'un compilo dans un EDI est quand même plus efficace d'autant plus que si les shaders sont programmables, la fonction reste quand même globalement statique (d'où l'intérêt de la compiler une bonne fois pour toute).
 
Mais comme tu le dis si bien, l'avenir nous le dira

mareek a écrit:
 
Nicolas_b utilise une technique de troll classique qui consiste a embrouiller les esprits avec des infos réelles mais sans rapport directe avec la discussion. Il peut ainsi gagner en crédibilité et semer le doute chez les indécis.
 
 
     

C'est pour ca que j'attend doom3 de pied ferme:
il a du etre ecrit avec un code de base en opengl (qui donc utilise les fonction opengl standart cad celles des GF1) puis faire uneversion par cg, si je m'en fait pas trop pour ati et nvidia, si un autre acteur veux revenir sur l marché, ds un premier temps il sera ds la merde vu k'il aura des graphismes basiques

Justement, pour Doom III, il y a un code généric OpenGL 2.0 (ou ce qui sera 2.0) et un code spécifique Geforce FX... parceque même le code généric Open GL est lent sur Geforce fx. Les ATI utiliserons le code généric sans problème...

c'est deja finalisé opengl 2.0 ?
meme le site openGL n'en parle pas ?

 
Nan, pas du tout !
 
Il y a le codepath ARB : niveau GF256 et 2. Il sert de basse au reste.
Il y a le codepath nV20 : GF3/4. Accélère SEULEMENT les choses.
Il y a le codepath R200 : Idem pour R8500 et associés.
Il y a le codepath nV30 : Idem pour GFFX.
Il y a le codepath ARB2 : Générique avec pixel shaders.
 
Les codepath ARB et ARB2 sont des codepath génériques.
En aucun cas ARB2 = OpenGL 2 !
 
ARB se contente d'une carte DX7 standard.
ARB2 se contente d'une carte DX9 standard.
 
Je le répète : ARB2 =/= OpenGL 2 !
 
Les codepath nV20, nV30, R200 et ARB2 sont identiques niveau résultat à l'écran (grosso modo, excepté la précision de rendu) au codepath ARB. Seulement, ces codepaths, contrairement au codepath ARB, utilisent les Pixel Shaders (Fragment Shaders en OpenGL) pour rendre les choses plus rapides en diminuant le nombre de passes et pour profiter d'une précision accrue.
 
ARB : équivalent DX7 : pas de PS.
nV20 : Utilisation des PS 1.1 (1.3 ?).
R200 : Utilisation PS 1.4.
nV30 : Utilisation PS 2.0 bidouillés de manière à tourner de façon convenable.
ARB2 : PS 2.0 "standards" (supportés par S3, XGI, et.... ATI, mais aussi nVIDIA avec les FX, mais avec des difficultés question vitesse.)
 
Un simple GF256 sera capable de tout afficher point de vue effets. Seule leur précision et leur vitesse variera.
 
Et oui, Doom3 utilise des effets très simples..... Vais linker vers l'artoche de PPC tiens....
 
http://www.presence-pc.com/articlev3.php?article=95
 
Et par la même occase je linke le dossier sur les langages de haut niveau de DirectX, OpenGL et Cg...
 
http://www.presence-pc.com/articlev3.php?article=97

donc si j'ai une carte qui fait les shader mais pas dx9 je l'ai ds les dent, il est beau l'api standart

De toute façon si tu as une carte comme çà, çà fait un moment que tu aurais du remarqué que tu l'as dans les dents.

 
non, justement, le hardware évolue plus vite que le software.
 
avec un compilo "statique", comment vas-tu faire pour optimiser pour du matos dont tu n'as pas les détail d'implémentation ?
 
la fonction est statique, d'un point de vue langage C, mais ce qu'il faut te dire c'est qu'entre X GPUs différents, tu peux avoir des différences d'implémentations interne aussi importante qu'il peux y en avoir entre des P3/P4/Athlon/PowerPC/Itanium....
 
DirectX 9 est ce qu'il y a de mieux à l'heure actuelle c'est vrai (tant que l'OpenGl 2.0 est à l'état prototypesque même très avancé), mais il faut reconnaitre qu'intégrer la couche compilo (ou génération de (µ)code GPU) au niveau driver est l'évolution à venir.

Uai mais avec DX elle tourne au max de ces posibilité, avec OpenGL il faut ke les developpeur fasse une version specifique :
acheteur de Xabre votre avis ?  

 
Non tu n'as pas compris : à partir du moment où tu as une carte au "niveau de fonctionnalités DirectX 7" (R100, NV10, NV15,...)tu pourras bénéficier de tous les effets même s'il faut quand même reconnaître que ces cartes n'auront pas la vitesse suffisante pour pouvoir faire tourner Doom III convenablement.
 
De toute façon quelle que soit ta carte tu peux te dire que tu disposes d'un code path utilisant au mieux ton matos ça se passe comme ça avec Carmack

 
Je suis entièrement d'accord avec toi mais :
1-ce n'est pas ce que nicolas_b dis, tout du moins pas ce que j'ai compris. Lui il parle du Cg toi e GLslang. Le Cg compile vers l'assembleur intermédiaire de l'API. On ne bénéficie donc pas de toute la liberté d'optimisation que permet un compilo intégré au driver vu que cette première passe effectue déjà un nivellement par le bas en ne déterminant le plus grand ensemble de fonctionnalitées communes aux différents hardware et en écartant les spécifictés propres à chacun.
 
Par exemple le NV30 dispose d'instructions sinus et cosinus câblées comme le dit Kirk dans son interview mais celles ci ne sont exposées que dans les extensions de nVidia et Cg ne permet de les exploiter que si l'on compile vers ce profile. A l'inverse un compilateur au niveau du driver permettrait de les exploiter vu qu'il serait lié au hardware sous jacent mais ça comme tu le dis c'est l'approche GLslang et pas celle de Cg.
 
2-comme je l'ai dis précédemment tout n'est pas faux dans ce qu'il raconte mais il mélange tellement de choses et de concepts différents que c'est difficile de s'y retrouver entre les affirmations "à peu près exactes" et celles entièrement fausses.
 
Enfin intégré le compilo au niveau du driver ne présente pas que des avantages, outre le fait qu'écrire un compilateur est complexe et si ATI et nVidia n'auront aucun mal à le faire certaines petites structures ne pourront sans doute pas s'y consacrer et puis ça introduit un facteur "aléatoire" dans le sens où le développeur ne peut plus être assurré de la compatiblité de son shader v que ça dépendra de la version du compilateur utilisé par chaque machine cliente alors qu'ave l'approche actuelle il peut précompiler son shader avec une version fixée du compilo et le livrer tel quel à l'identique sur toutes les machines clientes.

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