Reprise du message précédent :
kler, ca s'appelle manipuler les chiffres pour faire passer le message qu'on veut, technique bien rodé en politique:lol:

comme quoi tout est relatif.

Quoique dans le cas des Vol-pas-haut, c'est un vrai énorme fossé  
 
par contre, un graphe comme ça, c'est sympathique. Certainement pas parfait, mais sympathique. Par contre, le fait d'utiliser une alpha leaké, là, c'est moins parfait, on connaît pas la représentativité des chiffres...
 

 

 
http://www.xbitlabs.com/articles/e [...] alker.html

ce qui est interressant avec leur bench, c'est que pour l'instant le moteur semble limité par les performances géométriques.
 
en effet on voit la 5700 au même niveau que la 5900, et respectivement la 5600 et la 9600 à la moitiée de la 5700/5900 et 9800(9700 potentiellement).

Si on était limité uniquement par la géométrie, les écarts entre les cartes devraient changer quand on passe de 1024 a 1280 puis 1600, or ce n'est pas vraiment le cas. Il doit y'avoir un autre prob.

Certains disent, d'apes la concordance des dates (date de la version leakée et avancement du jeu) , qu 'il n' y a pas (ou peu ) de fonctions DX9.0 .

mmm....
 
si on regarde les autre graphes:
 
http://www.xbitlabs.com/articles/e [...] ker_5.html
 
j'allais dire ça:
 

 
mais c'est vrai que c'est intriguant de voir les fps baisser de 1024x768 à 1600x1200, et de ne pas voir d'écart se creuser entre la 5700 et la 5900, là où pourtant le fillrate devrait se poser en maitre.
 
y'a une optimisation de l'architecture de la 5900 à la 5950 ?

mmm...
apparement le moteur doit utiliser beaucoup de singletexturing, vu que la 5900 est en 4x2, et la 5700 est en 4x1, c'est la seule raison que je verrais pour que la 5700 talonne la 5900.

et conséquence interressante:
 

 

 
comme la 5700utlra est à 475mhz de core, elle peut battre la 5900 à 400mhz, en single texturing ?   my god

Sur un jeu qui utilise massivement les shaders, une architecture 4x2 n'est pas meilleur qu'une 4x1. Ca se verifiait en partie sur les benchs de HL2. MAIS :
-Les benchs d'HL n'étaient pas exmept de toutes incohérences.
-On sait peu de chose finalement du moteur graphique de Stalker, si ce n'est que ca s'annonce tres beau.

tes shaders, ça dépends combien de textures ils utilisent.
évidemment qu'en DX6, DX7, DX8, DX9 ou en Opengl, une architecture 4x2 aura le double de fillrate qu'une 4x1 si tu utilises deux textures au lieu d'une...

par contre ça laisse sous entendre que nvidia a revu les unitées de la 5950 pour qu'elle puisse faire du 8x1 dans plus de cas de figure qu'une 5800/5900 ? (au alors beans au niveau pilote pour les < 5950 qui restent en 4x2 là où elle pourrait faire du 8x1 en single texturing ?)

Marc, t'as pas un 5900 et une 5950 pour voir d'en autres jeux qui font massivement du mono-texturing y'a une grosse différence ?

A mon avis il faut pas interpreter les resultat dans la globalité ( on a eu l exemple d'Halo) .  
Pour le fillrate maximum d'une carte lorsqu'elle travaille en pixel shader, Tridam avait fait un dossier complet avec des calculs , faudrait le retrouver

 
c'est vrai quand dans le cas d'un shader y'a du recouvrement de temps entre la partie calculatoire et la partie échantillonnage... (en tous cas l'herbe quand tu est au ras du sol qui doit consommer une grande partie du temps de traçage dû à l'overdraw que ça génère, bin là une archi 8x1 retourne une archi 4x2, qui va aussi vite qu'une 4x1 )
 
spa faux, mais en même temps dans l'immédiat je doutes que le moteur de terrain de stalker utilise des shaders compliqué au niveau calculatoire.
 
enfin wait & see...

J'avais vérifié au cas où quand j'ai testé la carte mais il n'y a pas de changement de ce type dans la 5950. Soit les scores de xbitlabs sont faux soit il y a un path hyper optimisé pour la 5950 ou pour les cartes avec 256 Mo.
 
Quoi qu'il en soit ces scores sont bizarres à plus d'un titre. Il vaut mieux attendre de voir quelque chose de plus finale. D'après ce que j'ai entendu dire il n'y a pas grand chose de DX9 d'actif dans cette version leakée.
 
Il ne faut pas oublier qu'en shading, le FX5700 n'a que 2 pipelines alors que les 5900 en ont 4. Il n'y a que dans le cas du single texturing que le FX5700 peut se montrer au même niveau que les 5900. Dans tous les autres cas il dispose d'un fillrate 2x inférieur !

donc ça converge vers l'idée que pour l'instant stalker a bonne proportion de single texturing.
 
par contre si tout ce qui est bump, n'est pas présent, ça risque de remettre les pendules à l'heure...
 
que les 256 Mo aient une aussi grosse influance, ça paraitrait énorme, la différence 9800pro/xt semble de manière prévisible indexée sur la fréquence core.

Voila l'expliaction clairement formulée. Et justement je pensais que la 5700 disposait de 4 pipelines en shaders et non 2. Pour DX 9.0 on a du entendre les memes rumeurs. J'ai l'impression aussi que l'appelation "DX9.0" regroupe un peu tout et n'importe quoi. Quoiqu'il en soit avec l'année 2004 on devrait avoir quelques vraies application DX9.

bjone c'est lié aux 256 Mo de la carte
 
Regarde les différences entre 9800XT et 9800 Pro en 1600 AA4x+8AF, elles sont également plus importantes que les différences pures qui devraient découlées des fréquences. Dans une moindre mesure certes, mais tout de même.

ouai, mais sur cet autre graphe là:
 

 
9800pro/xt, c'est toujours cohérent par rapport à la fréquence, alors que la 5950 mets une baffe à la 5900 qui est toujours talonnée par la 5700.
 
enfin y'a quand même des trucs bizarres...

ou alors le FSAA+AF est moins pénalisant sur la 5950 par rapport à 5900 (réoptimisation à ce niveau ?)

Non non. C'est simplement que ATI s'en sort mieux au niveau de la gestion mémoire dans des conditions extrèmes, cela étant d'ailleurs peut être lié à leur aniso particulier.

c'est peut-être une 9800pro 256 Mo pour le test

 
là c'est pas impossible non plus, mipmaps de bas niveau utilisés plus fréquemment permettant de faire cycler plus rapidement les mipmaps entre la ram vidéo et la ram système.
 
en même temps le driver doit maintenir toute la chaine de mipmap simultanément (je doutes qu'il soit capable de faire l'upload de mimaps spécifiques en ram vidéo, soit toute la chaine est en ram vidéo, soit elle en ram système ou agp)
 
et je suppose que la chaine de mimaps est potentiellement identique entre une ati et une nvidia, la manière d'échantillonner change, mais le format des surfaces doit être le même ? (quoique c'est vrai que dans les détos et les catalysts on peut changer la qualitée de la génération de mimaps à la volée, dumoins à la création de textures)
 
pi le coup du FSAA+AF amélioré sur la 5950 est pas possible, on l'aurait vu ailleurs...
 
bon je cherches ptet la pitite bête

de prime abord j'ai pensé à la quantité de mémoire aussi...

 
Nope on n'est pas sur PS2 (qui doit gerer les niveaux de mip maps a la main..quand elle le fait).
 
La solution la plus proche qui est annoncée pour Dx10 (2005/2006), sera l'adressage virtuel depuis le GPU. D'ici là on sera forcé de rajouter encore et toujours de la RAM sur les cartes et ce n'est pas sur que Dx10 y changera quelque chose puisqu'il est plus important de gagner dans les benchmarks.
 
Il y avait aussi le ClipMap décrit par [Tanner et al] et utilisé sur certaines stations Silicon Gfx mais qui ne sera probablement jamais utilisé sur des hardwares grand public.
 
LeGreg

Non non tu as raison de la chercher. Mais j'avais déjà remarqué ce problème (si on peux appeller ca un problème) de gestion mémoire sur les 5900 avec une certaine révision de drivers sous UT2K3 :
 
http://www.hardware.fr/articles/472/page8.html

Sinon pour ceux que ça interresse, j'ai pu observé l'objet de désir, et c'est un version compilée du 19 mai 2002 (cf log d'éxécution), et c'est du DirectX 8.
C'est pas trop mal pour un beta qui a deux ans.
 
Contrairement à alf-leufe², au moins là à par quelque textures, y'a pas bien grand chose de récent qui a fuité....
 
sinon wait & see pour le reste.

de quoi tu parles ? une beta d'hl2 de mi 2002 ?

naon strolkeur

remarque je dis une connerie, la version d'xbit, c'est pas la version qui a coulée... (quoique )

Si si.
 
Mais bon xbit utilise des versions pirates des jeux pour faire ses benchs, est à la rue dans certains de ses tests etc..
 
Effectivement c'est difficile de comparer des applis qui utilisent un chemin ou un autre sur une carte. Tout au plus on peut comparer les chiffres sur des familles presque équivalentes de hardware (de la meme marque). mais comparer les chiffres entre les marques ou les generations differentes est difficile et n'a pas de sens sur la plupart des programmes bien écrits (bien écrits donc qui sont écrits pour maximiser le bonheur des joueurs donc la fluidité quelle que soit le hardware).
 
Ceci dit ce n'est pas pour aller dans le sens du poil dans la main des reviewers. Personne ne leur a dit qu'ils auraient a faire tourner un bench dans la nuit et mettre les chiffres tel quels au matin pour récolter leur gagne pain.  
 
LeGreg

article intéressant d'onversity (comme d'hab ):
http://www.onversity.com/cgi-bin/p [...] P=last#160

En fait la methode est assez ancienne (malgré son apparition récente sur les forums openGL) et était déjà exploitée (par exemple) par la démo de rendu de gazon de nvidia:
http://developer.nvidia.com/object [...] 0Rendering
 
LeGreg

d'ailleurs tiens question LeGreg, la binormale toi tu la stockes précalculée dans le vertex, ou tu la génère au vol par un produit vectoriel dans le VertexShader ? ( bande-passante mémoire vs temps VS ? )

 
Humm .. j'ai comme un doute,mais pourquoi pas. fais en part a l'auteur sur le forum d'opengl.org.
 
mais rien que dans l'explication Nvidia je note 3 points différents.
 
1 - utilisation des vertex shader
2 - méthode multi-pass
3 - Destiné a tout ce qui est fur (fourrure)
 
En fait il n'y a aucune mention dans le cas du bump. Le principe de la méthode de Terry welsh était plus ou moins connu, mais il est le premier a avoir trouver cette application dans le cas du bump et la manière de faire en sorte de génèrer peu d'artefacts.

spa faux.
 
sinon la technique me plait en tous cas elle est notée dans un coin
 

donc si je comprends bien pas de displacement dans serious sam 2
 
pacq je veux bien que ça bouffe en ressource, mais pkoi pas l'intégrer quand même et laissé le choix à l'utilisateur, plutot que de nous faire attendre l'OBM ?  

 
la methode est multipass parce que les hardware de l'époque ne supportait que quatre texture read par passe. A l'heure actuelle ça doit etre possible de le faire en une seule passe.
 
Ceci dit c'est vrai que strictement parlant les deux méthodes sont très différentes, mais l'idée et le principe est la meme: reproduire l'effet de parallax sur une surface en 2d.  
Je me souviens que pendant mon stage en mai 2000, mon maitre de stage m'avait déjà proposé plutot que de dessiner la géométrie de détail, de stocker des représentations view dépendantes dans une texture (une seule texture avec des coordonnées qui varient ou une texture de volume) mais c'est vrai que ça a moins d'interet sans fragment shader et avec un multitexturing limité à deux texture (sur l'origin de l'époque).  
 
A+
LeGreg
 
PS:
Barbarella,  
 
j'ai un probleme avec ce screenshot

qui ne montre pas l'interet de l'effet de parallax
mais montre simplement une différence dans le calcul d'éclairage.
Il faudrait probablement les mettre en plus gros et utiliser un éclairage consistant entre les deux (si c'est possible).
 
La c'est plus visible par exemple :

 
tiens c'est bizarre moi c'est plutot la normale que j'aurais calculé à la volée en fonction de la binormale et de la tangente  
mais qu'est-ce que j'en sais
 
LeGreg

 
De toute façon il faudra attendre pour le displacement mapping (moitié de l'année 2004?). L'interet de l'Offset BM (mal choisi comme nom) c'est que c'est utilisable tout de suite.
Le nom d'offset bump mapping est mal choisi parce qu'il peut etre confondu avec l'offset bump mapping qui consiste a additionner et soustraire la map de bump avec un offset et qui était utilisé sur les cartes de niveau TNT pour faire du bump mapping. Et aussi confondu avec l'offset bump mapping qui additionne un offset 2d issu d'une texture avant de faire un texture read pour faire un pseudo environment mapping (geforce 3).
 
LeGreg