Reprise du message précédent :

Parce que les CG actuelles ont pas assez de puissance geometrique comparé a leur supposé capacité de rendu du aux VS C'est un peu comme le TruForm... Quand on sais que seul l'ATI R200 le gere en Hardware... Forcement ca aide pas a gagnez quelques perfs et a avoir des meilleurs modeles. Si un jour, ne serais-ce qu'un, NVIDIA ou ATI sortait une carte compatible 100% DX(n-1) (mais vraiment 100% einh) et ~75% compatible DX(n) je serais vraiment impressioné ... C'est vrai quoi, faire a la fois les RT-Patches et les N-Patches dans une NV40/R400 ca me paraitrais deja pas mal pour des cartes DX9.1-class

 
Le premier avantage des nouveaux hardware c'est une puissance géométrique de plus en plus importante. Donc avoir un arbre sans les angles c'est déjà possible. Quand il y en a plusieurs à l'écran il faut gérer le "niveau de détail" géométrique pour l'instant ça se fait encore sur le CPU (contrairement au mipmapping des textures qui est un niveau de détail qui se fait sur le GPU).  
Ce que tu appelles des effets visuels, on peut voir plusieurs choses s'en rapprocher. On utilise déjà beaucoup les imposteurs qui sont des rendus plats mais qui conviennent très bien pour ce genre de choses lorsque le parallax ne joue pas. De plus des formes avancées d'impostures sont mises en oeuvres. Notamment Bionatics permet de réduire massivement la complexité des branchages avec des imposteurs. Cela demande du prétraitement et c'est possible à rendre sans hardware évolué. Il y a des formes d'impostures qui tirent parti des capacités de pixel shading des cartes graphiques. On a parlé ici depuis peu du rendu de l'effet de parallax à partir d'une surface plane. Ce n'était pas possible avant que les pixels shaders n'arrivent. Il y a aussi des formes de rendus volumétriques comme les voxels qui permettront peut-etre d'avoir des arbres ou des branchages stockés en volume.
 

 
Comme je l'ai dit, de nombreuses choses sont déjà possibles avec les PS2.0, avec au pire la nécéssité de faire plusieurs passes.
 
La simulation de la réfraction dans le verre et dans l'eau devient de plus en plus courante. Le rendu Cartoon est utilisé partout. Le blooming effect devient une nécessité. Les effets d'éclairage par pixels sont de plus en plus évolués.
 
Ce que les PS3.0 proposeront ce ne sera donc pas un saut qualitatif dans ce qu'il est possible de faire mais plutot une facilité de mise en oeuvre accrue et peut-etre la rapidité nécessaires pour que ce soit vraiment utilisé dans des jeux en temps réel. Certains effets qui étaient réservés aux démos techno seront peut-etre utilisés désormais dans les jeux de maniere intensive.
Tu as déjà des démos techniques d'effets qui ne sont pas prêts pour le prime time parce que le nombre de passes ou la dépendance au CPU était trop importantes. Ces effets seront adaptés et seront utilisables par la carte de monsieur tout le monde. Effets d'éclairage "global" précis par ondelettes, extraction des couches et éclairage anisotropique pour le rendu de fourrure, amélioration sensible de la réfraction à travers les objets non plans. Photon mapping temps réel. Et j'en passe.
 
A+
LeGreg

Rien qu'à te lire, LeGreg, je salive......
 
En parlant de charge et cie, vous avez essayé la démo de Far Cry ? Moi je suis dans le béta test multi... En tout cas, je trouve que ça promet

Ouais, je l'ai essayé : c'est monstrueux
 
Mais ma 9800 a du mal quand même

il y a aussi le bug des ombres sur les rochers ?
 
C'est beau, mais ça rame un poil quand même et je trouve les couleurs trop criardes

 
Ca change en bien justement les couleurs vives. Ca commence à devenir lassant les couloirs sombres
 
Je n'ai pas remarqué de bug ni sur Radeon 9800 ni sur FX 5950 sans FSAA. Par contre avec FSAA ça bug sur Radeon.
 
La Radeon 9800 Pro est devant la FX 5950 en terme de perfs. Pourtant il y a un path spécial FX.

Legreg -> pas mal ton lapin ! Je pense que d'ici 2 générations les cartes pourront rendre ce genre de chose suffisemment rapidement que pour être exploitable dans un jeu.
 
Les unités géométriques des GPU haut de gamme actuels sont clairement sous-exploitées C'est dommage. Pour le reste du GPU il suffit d'augmenter la résolution ou le FSAA ou la qualité du filtrage. Mais on peut rarement profiter de la puissance géométrique avec plus de polygones etc. En général l'option max des jeux passe sur un GPU d'entrée de gamme.  
 
Enfin il y a moyen de faire bosser plus la partie géométrique... Jouer à 1000 FPS en 320x240

Y a des screens avec les bugs de l'aniso sur le topic de la démo de Far Cry dans la cat JV. Mais bon, là, j'ai pas trop le temps de les chercher
 
Mais bon, peut-etre que c'est le FSAA qui les provoquent en fait (mais c'est plus des problèmes de textures on dirait).

 
Je n'ai pas remarqué de bug avec l'aniso. Ca doit venir du FSAA. EN gros le problème que j'ai vu ce sont des triangles non texturés qui deviennent donc transparents ou mauves.

Il utilise quoi ce jeu comme effets? Une idée ?

Les bugs sont sur les rochers et ce sont aussi des triangles mal-texturés. Ca doit être le même problème. Je te retrouve les screenshots ce soir  
 
Et ca vient peut-etre du FSAA. En fait, j'ai essayé que 2 modes : sans FSAA ni Aniso et avec FSAA et Aniso. Je disais que ca venait de l'aniso car c'est ce que disait la personne qui a posté les screens. Elle s'est peut-être trompée ...

 
Et d'après les béta testeurs, les FX sont automatiquement dirigées vers les PS 1.1, alors que les Radeon sont en 2.0 en very high....

 
ça doit venir de l'aniso, moi j'ai essayé avec et sans FSAA, mais pas sans aniso. Faudra que je revois ça. M'enfin, ATI est au jus, Catalysts Maker est venu rendre visite sur le forum BTFC.

Le screenshot avec le bug sur la Radeon : http://forum.hardware.fr/forum2.ph [...] 0#t1695135

Le bug ca vient des 2
G essayé avec aniso sans FSAA et sans aniso avec FSAA et ya le bug des textures...
Mais bon dans tous les cas Vive l'anisette !    

Yep
 
Et vive le yaourt aussi

 
C'est faux. Sur Radeon il y a pas mal de PS2.0 et sur GeForce FX des PS2.x. Je n'ai pas comparé le nombre mais il y a bien des PS2 avec les GeForce FX.
 
Note que le jeu utilise massivement les PS1.1 et un peu les PS2.0 de toute manière.

je trouve qu'il est trop détaillé ce jeu, sur la démo y a tellement de foret que je me fais surprendre par les ennemis   , je joue pas assez fino.
 
Enfin bref si on aime le genre c'est excellent.

Ah ca, c'est sur que le Serious Sam staille est pas trop adapté à ce jeu

Comment tu t'y prends pour "compter" (si c'est pas indscret) ?

 
Il y a eu un topic sur le forum officiel avec la comparaison des logs, et autant sur Radeon on a ça :
 

 
Autant sur FX ça correspond à ça :
 

 
Apparemment des gens essayent de forcer les PS 2.0 sur FX en bricolant avec 3DAnalyze... J'peux vous dire que la démo est dissèquée....

Hello,
quelqu'un à une idée de la RAM qu'il y a dans la Prolink Pixelview 5900XT ?  
 
Merci.

 
Moi je peux te dire que le jeu et ensuite le driver envoient bien des PS2.x au GPU. Pas des PS2.0, mais bien des PS2.x.

M'ouais, certainement un bug du jeu qui loggue mal
 
Enfin, je vois pas d'autres explication si le jeu envoie bien des PS 2.x au GPU.....

bah tu peux le dire mais sans source on peut pas te croire

 
C'est quoi cette manie de toujours demander une source ? Il faut un lien vers un site en english-parce-que-ça-fait-plus-vrai à chaque fois qu'on dit qqch ?
 
Il suffit de regarder ce qui est envoyé à la cg... Il y a des PS2.x... C'est pas plus compliqué que ça. Pas besoin d'une source sur le net, je sais encore le faire moi-même

Explique, ça m'intéresse!

 
Effectivement, la question est de savoir comment on s'y prend pour capturer les communications jeu/CG... version SDK de DX9 ?
 
En tout cas, tu m'expliqueras pourquoi dans le log tous ceux en fx ayant posté leur log (forum officiel béta) a un revert back en PS 1.1.... Soit y'a détection pour la version SDK de DX9, soit le loggueur est particulièrement bourré, soit tu as de la chance de ne pas faire un revert-back, soit ils ont tous foiré quelque chose dans leur install....  

C'est quoi ce fameux loggueur ???
 
Note que je n'ai vérifié qu'avec la FX 5950. Je n'ai pas vérifié avec d'autres FX.

Pour intercepter ce qui est envoyé à la cg, j'utilise un outil que m'a passé un très bon pote.
 
Mais certains softs comme 3d analyze permettent déjà d'intercepter un certain nombre de choses. Les shader en tout cas.

bah tu as le truc Tommti pour ça non ? (xact c'est 3D Analyse)

Bon j'ai revérifié et j'ai compté le nombre de PS2 utilisés sur un morceau de la démo.  
 
La FX utilise bien les PS2. Ils ne sont pas uniquement envoyés à la carte graphique, ils sont aussi calculés et affichés
 
Sur le morceau de démo :
 
Le path de la FX utilise 58 PS 2.x presque entièrement en FP16 (_pp sur toutes les instructions).
 
Le path de la Radeon (ou le path général probablement) utilise 78 PS 2.0 majoritairement en FP24/32 (_pp uniquement utilisé de temps en temps sur une ou l'autre instruction).
 
Notez que le nombre de PS2 est approximatif vu que le chemin parcouru peut avoir varié légèrement. Il ne représente pas non plus le nombre de shader différents car le même shader peut être envoyé plusieurs fois.
 
 
Sinon, sur FX5950 en 1024 et sans FSAA, on atteint rapidement les 200 Mo de mémoire utilisés QUi a dit que 256 Mo ça ne servait à rien ?

 
   
Quand Tridam parle tout s'eclaire    
Si la fx utilise des shaders FP16 , on est en deca des specifications DX9.0 ? C'est visiblement moins beau ?

 
Le FP16 fait partie de DX9. Par défaut ça doit être minimum du FP24, mais si le programmeur le décide, la précision peut être réduite au FP16.
 
Je n'ai remarqué aucune différence de qualité. Il y a quand même quelques instructions en FP32 sur la path de la GeForce FX. Peu mais il y en a donc je suppose que les développeurs se sont arrangés pour ne pas toucher à la qualité.

bah désolé,ça n'a rien contre toi spécialement mais si tu commences à ne plus vérifier les sources des gens sur les forums,la terre sera bientôt plate...
 
Jdis pas que t'es incompétent,je pense même le contraire,mais j'avoue que je préfèrerai pouvoir faire moi même l'éxpèrience pour vérifier ce que tu dis (et qui va à l'encontre de tout ce qui a été publié sur le net jusqu'ici ),mais apparement c'est pas possible puisque c'est un outil que seuls toi et un de tes potes possedez

 
Bah tu peux faire +/- la même chose avec 3D Analyze qui est public

 
Heink ?
 
Fp32 sur une radeon ?
Tu as fumé mon petit Damien
 
LeGreg

 
FP16 est le minimum requis par les PS2.0  
et ce sera également le minimum requis par les PS3.0.
 
Plus exactement il y a bien deux niveaux de calcul, l'un qui conserve la précision avec un cout de stockage intermédiaire supplémentaire et l'autre qui garde une précision raisonnable. La précision raisonnable est largement suffisante si par exemple tu as 8 bits fixe en entrée et 8 bits fixe en sortie ce qui reste vrai pour la majorité des jeux actuels.
 
Bien entendu l'optimiseur inclu dans le driver peut prendre des décisions partielles sur la précision à traiter mais l'idéal reste tout de meme que ce soit le programmeur qui le fasse puisque c'est le seul à connaitre l'intervalle de validité des données (est-ce que ce sont des couleurs ? des coordonnées?).
 
A+
LeGreg

 
Je ne parlais pas de FP32 sur Radeon mais vu que c'est le path général il utilise la pleine précision donc FP24 ou FP32 suivant le hardware qui le fait tourner.

 
Il faut quand même bien rappeler que la seule chose requise c'est du FP24 minimum. Par défaut le format doit être FP24 minimum. Le FP16 c'est un format de calcul optionnel qui ne fonctionne que si le programmeur et le fabricant du GPU l'ont voulu ainsi. D'après ce que je sais, le compilo de NVIDIA n'y touche pas, encore heureux.
 
Il faut aussi ne pas oublier que le FP16 n'est pas spécialement un format d'avenir en tant que format de calcul (ce qui est différent du stockage bien entendu). Le FP16 n'a été mis en place dans DX9 que sur le fil et à la demande de NVIDIA. Tout cela a été fait tardivement car NVIDIA à tardé à dire que son architecture était limitée par rapport aux registres et à priori à certains datapaths internes également. Il n'y a pas de FP16 dans OpenGL par exemple. (ne pas confondre OpenGL et NVOGL qui est aussi propriétaire que le glide) Si l'architecture de NVIDIA n'avait pas présenté ce problème, il n'y aurait jamais eu de FP16.
 
Les NV4x étant basés sur la même archi, le FP16 leur est toujours utile puisqu'il permet de doubler le nombre de registres accessibles quand le pipe est full. Ceci dit dans une moindre mesure car NVIDIA ne pouvant pas continuer avec un nombre si réduits de registres relatifs il a été augmenté.

Tu regarde le log.txt....