Reprise du message précédent :

je parlais d'une comparaison voodoo5/gf1 ou 2 sur le même jeu.
La voodoo5 se contente d'un bus PCI sans ralentir.
en fait le cpu va calculer les coordonnées/couleur d'UN point pendant que la carte va tracer un polygone de 10*10 pixels avec plusieurs couches de texture. Alors heureusement que la mémoire vidéo va + vite!
 

ce facteur 7 n'est surement pas vérifié en faisant la même quantité de calculs sur chaque polygone. Il suffit de regarder le nombre de transistors et la fréquence des gf1 et gf4.

hihi ça vole haut ce soir, on a dépassé le stade Ati vs Nvidia....
 
ça fait plaisir quand même...
Ce qui méclate c'est le temps d'argumenter une réponse, y'a eu 2/3 trucs qui sont postés derrières...

arf,
 
j'ai oublié de donner mon avis sur UT. en fait actuellement c'est plutot ça programmation qui déconne. quand t'augmentes les perf CPU t'as une augmentation presque linéaire avec les FPS (j'ai dit presque) en tout cas avec ma 8500 LE. Quand je passe mon P4 de 1,6 a 2,13 GHz j'ai 30% de gain environ.
 
mais bon c'est un prog prevu pour le glide, pas DX ou opengl.

 
oui, ça change c'est cool

 
bin la fréquence et le nombre d'unités ont augmentés, donc oui le coef x7 est là à même configuration de vertex...
 
d'ailleurs les unités géométriques de la gf4 ont moins de pénalités en cycles que la gf1 lorsque tu montes en complexité de calcul...
 
je suis en plein dans un moteur de stripification de mesh, et j'ai parcouru le stripifier de nvidia, et les docs parlant de l'importance de l'organisation du flux d'indice pour rentabiliser le cache à vertex post-T&L/Vertex Shader...

[jfdsdjhfuetppo]--Message édité par bjone le 29-05-2002 à 01:40:00--[/jfdsdjhfuetppo]

le P4 avec son architecture bizzare c'est un cas assez articulier
le cyrix étit pourri en fpu, c'était à l'époque où on commençait juste à l'utiliser.
maintenant un soft x86 'de base sans fpu ni MMX' optimisé pentium tournera à peu près correctement du 486 à l'athlon XP.
un soft 3dnow optimisé K6-2 ne pénalisera pas beaucoup l'athlon.
Ce qui pose problème c'est l'utilisation d'un jeu d'instruction différent selon le cpu.
depuis qu'on a SSE sur tous les cpu, à mon avis ça va durer longtemps. Parce qu'on a pas vraiment de meilleure méthode pour faire ce genre de calculs, alors ils vont certainement pas nous pondre de nouvelles instructions pour ça. 3Dnow va être oublié car même usage mais nécessite un code différent, et pas dispo chez intel. SSE2 c'est pas une amélioration c'est un autre usage.

 
c'est vrai que tu as un peu raison....
d'ailleurs je t'invite à zieuter les datasheets de programmtion de l'itanium, y'a de super idées au niveau jeu d'instruction, les registres de prédication pour "noper"  les instructions au lieu de brancher (et risquer de mal prédire et purger le pipeline) c'est trop

t'as un bon algo pour faire des strips?
 

c'est vrai même si j'ai un peu l'impression d'avoir détourné le topic
 
barbarella dédolé ton exemple (enfin celui d'ATI) ne marche pas chez moi, j'ai qu'une vieille kyro2.
ça serait pas un truc de ce genre?
http://www.pvrdev.com/eg/h/Fur.htm
dis-moi si ton exemple fait des choses en +, ça m'intéresse.

bon,
 
je dois vous laisser les nenfants. juste pour finir :
 
L'epic y a de bonne idée, le prob c'est que ça marche pas fort en pratique. le Power 4 d'IBM a placé la barre très haut et l'itanium est très en dessous.

pitié j'ai déjà la crève, il faut que je me plonge dans le SSE et dans la migration vers opengl de mon moteur 3D

 
je test ton exemple et je reviesn

 
j'y travailles, au début je comprenais que de chi au stripifier de nvidia, j'ai fait un truc à moi pas trop mal, puis maintenant je comprends mieux comment ils procèdent...

oulalla,
 
la diffférence est enorme. Les poils subissent a la fois l'inertie et la gravité dans l'exemple d'ATI alors que l'objet avec plein de poil tourne dans tous les sens. pour qu'il fonctionne je suppose qu'il faut des shader peut-être même pour le pixel shader la ver 1.4 ?

en fait je dis ça parce qu'on m'a dit que la plupart des algos se valaient à peu de chose près, mais autant en être sûr avant de pondre rapidement un algo pourri.

[citation][nom]wave a écrit[/nom]

 
Je ne parlais pas vraiment de la différence de vitesse entre la RAM et la RAM vidéo mais plus dans l'envoit d'informations via la bus AGP. Une fois tes vertices transformés il faut bien les envoyer au proc vidéo pour qu'il se charge du clipping, du triangle setup et de la rasterization t'es d'accord ? Je ne sais pas quelle est la bande passante maximale en écriture via l'AGP mais je pense pas que ça doit voler trés haut donc tu dois la saturer rapidement. Je me rappele d'une interview de Carmack (décidément ) où il disait que le PIII avait suffisamment de capacités en virgule flottante pour traiter les informations au fur et à mesure qu'elles arrivaient le problème était qu'il ne communiquait pas assez vite avec la mémoire et en particulier l'écriture dans le vertex buffer de la carte vidéo via l'AGP était un sacré goulet d'étranglement.
 

 
Je pensais à des polygones en flat et en strip pour maximiser les perfs des deux cartes tout en étant sûr que c'est la géométrie que l'on mesurait et franchement on doit pas être loin de ce facteur dans la pratique.

ça doit faire bosser les vertex shaders pour l'inertie et la gravité. après les pixels peut-etre pour l'éclairage (j'en sais rien), mais sans doute pas pour les poils.

c'était pas à l'époque où une voodoo5 PCI n'avait pas ce problème et où carmack était à fond pro-nvidia?
c'est quand-même louche je trouve. Si 3dfx n'avais pas ce problème c'est qu'il est soluble.

Ouais un des problèmes de l'Itanium (pour changer encore complètement de conversation ) et qu'il est n'est pas OOO, son successseur le sera si je ne me plante pas, en outre il apportera de plus gros caches et de plus hautes fréquences. Bref comme on l'a souvent dit l'Itanium n'était qu'un coup d'essai destiné à prouver que l'architecture EPIC était viable, commercialement il était mort avant d'être sorti. Son successeur (conçu en collaboration avec HP contrairement à l'Itanium qui est un pur produit intel) devrait placer la barre bien plus haut mais c'est vrai que le Power4 est redoutable

 
oui il doit evidement utiliser le Ps pour l'éclairage diffu et spéculaire. Claire que les vertex c'est pour les mouvements de poils
 
non, c'est impressionnant et ça consomme pas trop de processeur j'arrive a t'écrire alors qu'il tourne en tache de fond en fenetre win.

[jfdsdjhfuetppo]--Message édité par barbarella le 29-05-2002 à 02:04:32--[/jfdsdjhfuetppo]

(je suis en direct3d, donc c'est vertex buffer/index buffer que je cause)
 
en fait tout peut aller, mais je cherches à faire un strip dégénéré le plus propre possible.
 
en fait au début je génére une liste de strips les plus long possibles.
 
pour ça j'ai 2 routines:
 
une qui me calcule la longueur du strip généré pour un triangle et un segment du triangle donné...
 
une qui me génére un strip, idem, pour un triangle et un segment donné...
--
j'ai donc une routine "d'exploration" rapide et une routine de "génération" lente (plus lente en tous cas vu qu'elle crée un bloc de mémoire avec les indices des vertexs)
   
et j'ai une boucle qui balaye tous les triangles et tous les segments de chaque triangle avec la routine d'exploration ce qui me donne la longeur max (et je sélectionne alors le couple triangle/segment idéal)
 
j'émets le strip du couple triangle/segment idéal
 
et je recommance tant que la longeur max est supérieur à une valeur (je me donnes 3 à 6 triangles minimums)
 
--
 
le stripifier de nvidia génére les strips en fonction de routines d'exploration qui partent de triangles séléctionnées pseudo-aléatoirement....
 
moi je suis parti dans l'idée que mon stripifier ne sera utilisé que par des devs/graphistes (ne sera pas utilisé au runtime), donc j'y ait été par brute-force. donc c'est plus long...
 
----
 
alors j'ai fait évolué mon truc:
 
donc j'ai une liste de strips "longs"  > 4-6 triangles
je cherche quand même les petits strips >= 2
 
les strips long sont convertis en un seul strip dégénéré
 
les petits strips >= 2 triangles, sont mis en tant que triangles indépendants, mais je cherche une "proximité" au niveau indice de vertex (afin de profiter du cache à vertex post t&l).
et tous les petits strips sont ainsi ensemble dans une liste de triangles indépendants.
 
les triangles non stripifiés sont rajoutés à la liste de triangles indépendants...
 
et je me retrouve avec un strip long qui couvre de 60 à 90% le modèle, et des triangles indépendants qui font le reste...
 
le flux d'indice, et les vertexs sont réorganisés afin de réorganiser les vertexs en mémoire...
de style si tu as comme série d'indice de vertexs:
avant: 0 405 7890 2 3 4 5
y'a remapping mémoire:
0->0
405->1
7890->2
2->3
3->4
....
 
afin que les accès mémoires sont contigus et dans la même page mémoire (car le changement de page mémoire est extrement douloureux pour l'AGP d'après nVidia, ça doit être lié au fonctionnement du GART)
 
le seul truc qui me chiffonne c'est que le stripifier de nVidia prends en compte la taille du cache à vertex post T&L, et j'ai pas encore compris comment il l'intégrais dans l'algo de strippification... (en tout cas il s'en sert d'une manière plus subtile que moa)

[jfdsdjhfuetppo]--Message édité par bjone le 29-05-2002 à 02:15:11--[/jfdsdjhfuetppo]

Zeross a écrit a écrit : Ouais un des problèmes de l'Itanium (pour changer encore complètement de conversation ) et qu'il est n'est pas OOO, son successseur le sera si je ne me plante pas, en outre il apportera de plus gros caches et de plus hautes fréquences. Bref comme on l'a souvent dit l'Itanium n'était qu'un coup d'essai destiné à prouver que l'architecture EPIC était viable, commercialement il était mort avant d'être sorti. Son successeur (conçu en collaboration avec HP contrairement à l'Itanium qui est un pur produit intel) devrait placer la barre bien plus haut mais c'est vrai que le Power4 est redoutable

 
qu'est-ce tu veux dire par OOO ? (merde un vieux acronyme que je connais poa)

Out Of Order pardon
 
bon je vous laisse fo que je re-visses mon alim...

[jfdsdjhfuetppo]--Message édité par bjone le 29-05-2002 à 02:17:41--[/jfdsdjhfuetppo]

OK merci pour les strips je garde ça sous le coude pour le jour où je m'y attaque.

bon allez bonne nuit @+

wave >> par contre je pensais à un truc ou la maitrise du SSE a son importance, c'est pour les systèmes de particules & co...
(up déguisé )

[jfdsdjhfuetppo]--Message édité par bjone le 29-05-2002 à 11:13:44--[/jfdsdjhfuetppo]

salut, putain g halluciné sur vos connaissances techniques en matiere de programmation et graphisme 3D, je vous félicite vraiment, etant moi meme un joueur confirmé...
bravo à tous!!!!

oui effectivement.
d'ailleurs pour bien faire (quand les particules sont des pixels et non des polygones) il faudrait tout faire au cpu, puis transférer le frame buffer créé dans la RAM vidéo en arrière-plan.
parce qu'appeler une API et lancer un traçage de polygone au lieu d'écrire un mot par particule au cpu c'est vrai que c'est pas rentable.

 
a propos de particules vous avez vu l'exemple de Humus ? arf faut que je retrouve le lien de son site avec les codes sources
 
mais là je serais aussi assez d'accord sur le coup de cpu.

zou le lien de son site
 
http://esprit.campus.luth.se/~humus/?page=3D

de quel exemple tu parles ? (y'en a plusieurs sur la page).
enfin vu les photos le cpu ne doit pas être utilisé pour l'affichage (juste pour les calculs) parce que c'est pas un pixel par particule.

 
si t'en a une qui s'appelle particule systeme et humus dit qu'elle fonctionne bien pour des gros cpu.

c'est joli mais je pense que le cpu doit calculer les mouvements, l'affichage doit etre un polygone envoyé à la carte.
enfin ça reste possible au cpu mais je vois pas trop l'intéret.

Pour revenir au sujet, Carmack a explicité  ses propos; conclusion: il a seulement dit R300 > GF4 hautement fréquencé . C'est tout et c'est normal comme il le souligne pour un chip qui a une génération d'avance par rapport à un produit déja sorti.
 
"It [The ATI card used] was compared against a very high speed GF4. It shouldn't be surprising that a next-generation card is faster than a current generation card. What will be very interesting is comparing the next gen cards (and the supporting drivers) from both vendors head to head when they are both in production.
 
Everyone working on DOOM still uses GF4-Ti cards at the moment, and if someone needs to buy a new video card today, that is what I tell them to get."
 
John Carmack
 
source http://www.nvnews.net/

[jfdsdjhfuetppo]--Message édité par MoB le 29-05-2002 à 20:52:53--[/jfdsdjhfuetppo]

moi je me pose une question: on sait que la radeon a davantage de fonctions (possibilité de mettre des programmes + complexes dans les shaders). Mais a-t-il la rapidité suffisante pour appliquer ces avantages sur la majorité des polygones d'un jeu?
parce qu'il ne semble pas forcément beaucoup + rapide sur un jeu qui tourne sur gf4.
Par contre c'est vrai qu'une génération d'avance, même sans la vitesse nécessaire, reste intéressant pour développer des jeux qui sortiront 1 ou 2 génération + tard.

Excellent ce topic!!! Bravo les gars.
 
Ce qui faut aussi dire c'est que bien en theorie la 8500 est superieur aux GF3 et GF4, sur certaine scene, sans que Carmack puisse l'expliqué, les GF4 sont devant.
 
Autre chose: alors que le T&L doit à la base faire une parti du travail que faisait le CPU ( donc le soulagé ), pkoi ils faut de plus en plus de gros CPU pour exploiter les derniers CG T&L ???
 
Est-ce que c'est paske, tout simplement, l'info de base ( les triangles ) ont enormement augmenté ou y a t-il une autre raison ??

[jfdsdjhfuetppo]--Message édité par DrDS le 29-05-2002 à 22:00:04--[/jfdsdjhfuetppo]

sur les gf1 y'avait clairement une raison due à une mauvaise conception: en T&L soft, elle demandait + de boulot et  de bande passante AGP qu'une voodoo5. Il semble que depuis ça se soit pas mal amélioré, mais dans un jeu il reste à faire des tests de collisions (qui demande que le cpu analyse, même s'il ne calcule pas, les coordonnées après rotations/translations. De +, un jeu ne fait pas qu'afficher de la 3D (physique, intelligence artificielle,...)
Il faudrait tester un moteur 100% T&L en dehors d'un jeu avec un petit cpu et un gros, à carte vidéo identique.

[jfdsdjhfuetppo]--Message édité par wave le 29-05-2002 à 22:22:10--[/jfdsdjhfuetppo]

barbarella a écrit a écrit : prenons un exemple   tu peux charger la démo ici

 
 
Oh putain un trou avec du poil !!!!!!!
 
 
Le rêve de toute une vie

il te suffy plus atos ?

barbarella a écrit a écrit : prenons un exemple   http://www.ati.com/developer/images/tkfurlg.jpg   tu peux charger la démo ici     http://www.ati.com/developer/indexsc.html   Une équipe allemande du Max planck institut fait la même chose avec une GF2 (ils l'ont fait avant d'ailleurs), mais il propose une méthode software du DM pour implantation en hardware.   PDF ici   http://www.mpi-sb.mpg.de/~jnkautz/ [...] ntGI01.pdf     Franchement sans DM est faire les calcul essentiellement en CPU je vois pas comment c'est possible

 
Si c'est la méthode que je connais, c'est pas si gourmand que ça, les poils sont en fait constitués de lamelles, enfin de faces en lamelles. On voit pas trop sur l'image et je n'ai pas la possibilité de voir la demo mais il semble bien qu'on les voit, cet espéce d'effet un peu crenelé surtout en bas.
 
En fait si c'est cette méthode, ça peut presque se faire en software, enfin pas de cette beauté c'est clair mais bon. Tu dessine pas des poils en faces 3D pour constituer la forme mais tu fais des lamelles qui bougeront selon le mouvement du poil ( il suffit de décaler les lamelles les une par rapport aux autres.  
 
C'est un procédé utilisé dans le domaine de la recherche 3D pour le milieu médical, afin de rendre une simulation d'opération la plus réaliste possible ( la fac de Grenoble faisait un exposé sur ce procédé y'a 2 ans )
 
Dans le milieu de la démo c'est également apparu, mais en full software, donc plus limité en nombre de poils et en rendu niveau reflets
 
n'empêche ça rend super bien et ça impressionne alors que c'est moins lourd que ce qu'on pourrait croire
 
Par contre je voudrais bien voir tout ça animé pour voir comment ils gérent les reflets parce que c'est surement le plus chiant du tout
 
P.S. : Ils ne disent pas combien de faces sont rendues dans la demo ?

koa ta meme pas de 8500 ?????