Bonjour,
je voudrais savoir combien de triangles par secondes peut calculer un P4 vers 2 GHz pour pouvoir comparer avec un GPU.
C'est pour un exposé.
Merci

Faudrait trouver un bench qui puisse fonctionner aussi en mode "software"

Quelqu'un aurait entendu parler d'un tel bench ?

Pose-toi d'abord la question : C'est quoi calculer un triangle ?

2 triangle par heure....

Si c'était possible d'éviter de jouer aux devinettes...  
Il me faudrait une réponse rapide merci !!!!  

grouiiik a écrit a écrit : Si c'était possible d'éviter de jouer aux devinettes...   Il me faudrait une réponse rapide merci !!!!

 
Oh hé faudrait y mettre un peu du tien aussi !
 
Compte pas sur nous pour faire ton boulot !

il faut que tu saches le nombres de cycle consumes par un calcul de triangle en moyenne et que tu fasse le ratio avec la puissance du proco.
 
Pas moyen autrement.
 
Cherche sur le net ce qu'il faut faire dans le cas d'un calcul de triangle...

c débile, ca dépend du prog qui calcule ... c pas en hard comme sur une carte graphique ...

Si je pose la question ici, c'est parce que j'ai pas trouvé l'info par moi-même.
Je demande juste si quelqu'un connait la réponse, c'est pas plus compliqué que ça.

 
c'est pour ça ke j'ai précisé un p4 vers 2 GHz.

 
On a qu'a admettre que le proco fait le meme type d'operation que le GPU.
 
Style faire le meme calcul prends au P4 X cycles, donc il en calcule X/seconde car il fait X Cycles / seconde.

J'ai trouvé qu'un P3 550 calcule 4 millions de triangles à la seconde.
Peut-on appliquer une bête règle de trois ?

 
on se fout de la vitesse, je te parle de l'algo, de l'optimisation des calculs matriciels, etc ...
 
le moteur de Q3 calcul plus de triangles que celui de quake en une seconde.
 
Calculer un triangle, c'est quoi ? juste calculer les coordonnées des points ? tracer les lignes entre ces points en plus ??? avec quel algorithme de tracé de lignes ??? Trouver les faces visibles ? implementer le clipping ?? Tu utilises quel proc ? FPU, CPU, MMX, SSE, SSE2 ???  
 
On ne peux pas reponde à ta question, au pire, met Q3 en mode logiciel, là c le proc qui fera tout.

 
Bon, on peut toujours essayer :  
p3 550 --> 4 m
p3 1100 --> 4 x 1.8 = 7.2 m
P3 2200 --> 7.2 x 1.8 = 12.96 m
P4 2200 --> 12.96 x 0.8 (archi netburst, ca doit être ca nan ? tetedeiench ? Un P4 1.4 GHz à les perfs d'un P3 1133 ?? ) = 10.368 (sans SSE2).

 
Je suis pas persuade que la regle soit appliuable via une regle de trois.
 
M'enfin, suffit de faire une recherche sur google...
 
A la base, un triangle c'est 3 sommets(nan ? ), et quelle operation on fait sur ce sommet...
 
Gaffe au pipelining ( different sur un P4 face a un P3).
 
Donc bon, je dirai que ta regle de trois est a 97% fausse.

qu'est-ce que tu entends par triangles/secs ?
 
la grandeur qui se donne en triangles/secs c'est les performances du triangle setup.
 
mais avant il faut transformer et éclairer les vertices.
 
sachant que suivant comment tu stoques tes triangles, il te faudra un nombre moyen variable de vertices par triangles.
 
avec un strip, tu auras 3 vertices pour le premier triangle, 1 vertex pour chaque nouveau triangle.
 
en triangles indépendants tu as 3 vertices (vertexs ? ) par triangle, mais les cartes 3D utilisent un cache Post-T&L qui conserve les derniers vertex tranformés, ce qui fait que la moyenne effective de vertices par triangle se rapproche de 1.
 
------
 
généralement pour une carte 3d le triangle setup et l'étape la moins pénalisante (ie: c'est rarement le goulet d'étranglement)
 
les deux goulets sont généralement la vitesse de remplissage (fillrate en Mpixels/secs ou Mtexels/secs si c'est une archtecture avec plusieures unitées de textures par pipeline), et l'unité T&L qui transforme et éclaire les vertexs (en vertexs/secs).
 
par abus de language on continue à parler de triangles/secs pour les performances géométriques, mais c'est faux, il faut parler de vertices/secs.
 
à l'heure actuelle, une geforce 4 plafonnne à ~100M vertexs/secs, ce qui donne dans les 55M triangles/secs.
 
ces 100M vertexs/secs sont uniquements atteingnables avec une source de lumière, et le temps pris par vertex à transformer/éclaire augmente en fonction du nombre des lumières et de leur nature (diffuse/séculaire, spot, directionnelle...)
et d'autres propriétés (coordonnées de textures générés par matricage, cube-mapping, etc, etc, etc...)
 
en vertex shader ça reste valable, mais c'est encore plus subtile car c'est du code variable ou il y a plus de notion de lumière & co (au niveau api)...
 

 
 
t optimiste.
bon, on va prendre le pb autrement :  
triangle : 3 points.
point : 1 matrice 4x4.
transformation d'une matrice 4x4 : 64 multiplications, 48 additions (4 multiplications et 3 additions par valeur, fois 16 valeurs), dans le pire des cas non optimisés (prise en compte des 0 de la matrice, etc ...)
 
donc, fo connaitre les cycles d'un P4 pour une addition et une multiplication, prendre en compte le fait qu'on utilise que la FPU, les ratés du cache, les rafraichissements de la DRAM, les accès RAM (RAMBUS, DDR ???), le cache L2 et L1, les vidages de pipeline, les prédictions de branchement, la parallélisation des calculs, l'age du capitaine, mais on obtiens à peu près :
 
3x (64 x cycles_multi_flottant + 48 x cycles_add_flottant) * Y de rendement, où les cycles sont ceux du proc en question et Y un nombre entre 0 et 2 representant l'état du proc et l'alignement des planètes au moment du calcul ... ce qui donne le nombre de cycles pour calculer un triangle, à repasser en millisecondes en fonction de la fréquence du processeur, et hop, regle de trois et on a le nb de tr/sec ...
 
Bref, ce genre de calcul est impossible depuis le 486, à cause des pipelines, prédictions, parralélismes, etc ...
 
 
ca se voit que j'ai que ca à faire ???

darkstalker a écrit a écrit :       t optimiste. bon, on va prendre le pb autrement :   triangle : 3 points. point : 1 matrice 4x4. transformation d'une matrice 4x4 : 64 multiplications, 48 additions (4 multiplications et 3 additions par valeur, fois 16 valeurs), dans le pire des cas non optimisés (prise en compte des 0 de la matrice, etc ...)   donc, fo connaitre les cycles d'un P4 pour une addition et une multiplication, prendre en compte le fait qu'on utilise que la FPU, les ratés du cache, les rafraichissements de la DRAM, les accès RAM (RAMBUS, DDR ???), le cache L2 et L1, les vidages de pipeline, les prédictions de branchement, la parallélisation des calculs, l'age du capitaine, mais on obtiens à peu près :   3x (64 x cycles_multi_flottant + 48 x cycles_add_flottant) * Y de rendement, où les cycles sont ceux du proc en question et Y un nombre entre 0 et 2 representant l'état du proc et l'alignement des planètes au moment du calcul ... ce qui donne le nombre de cycles pour calculer un triangle, à repasser en millisecondes en fonction de la fréquence du processeur, et hop, regle de trois et on a le nb de tr/sec ...   Bref, ce genre de calcul est impossible depuis le 486, à cause des pipelines, prédictions, parralélismes, etc ...     ca se voit que j'ai que ca à faire ???

 
   
 
un point (vertex) c'est pas une matrice 4x4.
la matrice 4x4 c'est qui tranforme le point (le ramène dans le repère de la caméra et effectue la mise en perspective)
 
un vertex non transformé ça fait en général pratique 8 floats ( position: x,y,z; normale nx,ny,nz, texture u,v).
8*4 floats = 32 octets.
 
un vertex transformé ça donne quelque chose de plus subtile:
position mise en perspective float: x,y, z pour le z-buffer, un w (correction de perspective lors du remplissage ?), dword: diffuse & spéculaire, float u,v : coordonnées de texture.
 
ce qui fait 6 float + 2 DWORD, donc 8*4, 32 octets toujours.
 
donc le FSB verra passer 64 octets (non transformé puis transformé & éclairé), comme FSB du P4 a une bande-passante de 4.26 Go/S (533 Mhz QDR, sur un bus de 64 bits), donc 4.26 Go / 64 octets => 68.16 Millions vertexs/secs.
 
je ne vois pas d'autre méthode d'estimation au blair comme ça...
 
le FSB sera le goulet avant les performances internes (fréquence cpu), et plus de performances internes (+ de fréquence ou + d'unitées) permettent d'utiliser des tranformations plus complexes...

ca m'etonnerais que la RAM soit le goulet ici. toi tu prend uniquement en compte le transfert des données de la ram au cache. fo les calculer après, et comme justement c'est le plus long, le temps de chargement devient sans interet puisque n'est pas l'element le plus lent.  
De toute facon, y'a trop de parametres, aussi bien logiciels que hardware, c pas jugeable ...
 
 
PS : avec ton calcul, le P4 dépasse la GF4 et le P3 fait 17M tr/sec, ce qui est utopique ...

dans tous les cas, les performances géométriques des meilleurs cartes 3d actuelle est (très) dur à atteindre au par un cpu, et en rapport/performances prix un cpu est complètement lourdé par une carte 3d.
 
si ton exposé cherche à mettre en évidence la différence carte 3d/cpu, l'argument est là: le rapport performances/prix.
 
d'autant plus qu'une appli écrite pour une carte 3d, profite directement de chaque nouvelle génération de gpu, alors que pour profiter d'un nouveau cpu, fo généralement re-compiler. (gain en temps de dev).

 
tout à fait.
 
heu: j'ai dit que la gf4 faisait 100 M vertexs/secs dans la pratique.
 
et j'ai supposé que TOUTE la bande passante théorique était consommé pour la tranformation et l'éclairage des vertexs.
hors dans la pratique....
 
les performances de la GF4 sont pratique, les performances de ce que le P4 pourrait donner au mieux sont théoriques

Bref, incalculable

après effecitvement, moi j'ai pris les performances crêtes en vertexs/secs.
 
mais après on pourrait relativiser les performances à haute complexité par vertex... beaucoup de lumières, et perturbations volontaire de la géométrie: les peformances internes deviennent plus importante que les problèmes de bande-passante, et là le cpu peut ptet être plus efficace que le gpu....
 
donc y'a trop de paramètres à prendre en compte....

darkstalker a écrit a écrit : Bref, incalculable

 
  assez difficile en effet.

juste un truc : avec ton calcul, le proc va aussi vite quelle que soit ca vitesse : un P3 600 va aussi vite qu'un P3S 1400
 
Enfin bon, on a pas inventé les 3Dfx, le T&L et les shaders pour rien

darkstalker a écrit a écrit : juste un truc : avec ton calcul, le proc va aussi vite quelle que soit ca vitesse : un P3 600 va aussi vite qu'un P3S 1400   Enfin bon, on a pas inventé les 3Dfx, le T&L et les shaders pour rien

 
merde, je me contredis moi meme comme un gros naze , j'ai dit que c pas la BP qui limite ... oulala, dodo ...    
 
 

darkstalker a écrit a écrit : juste un truc : avec ton calcul, le proc va aussi vite quelle que soit ca vitesse : un P3 600 va aussi vite qu'un P3S 1400   Enfin bon, on a pas inventé les 3Dfx, le T&L et les shaders pour rien

 
tout à fait.
les performances crêtes sont limitées par le goulot d'étranglement qu'est le FSB.
 
car la géométrie d'un objet étant certainement supérieure à la taille du cache, le cache ne sert pas dans ce cas là (il permet du recouvrement de temps entre le chargement des lignes et le traitement interne).
 
il y a des traitements qui peuvent profiter de la mémoire cache et d'autres non.
 
en plus au niveau du code il y a deux grandes approches:
 
celle des cpus (enfin je sais pas c'est ce que je faisait avant d'avoir une carte 3d, je suis pas une tronche non plus):
 
1) ton tableau source de vertexs non transformés, mettons 2 mo
 
2) tu prends un tableau destination de vertexs transformés (même nombre d'éléments, mais pas forcément taille mémoire identique), donc mettons 1 mo (ou 3 mo suivant ce qui est généré)
 
3) tu transforme chaque vertex de la source dans la destination
=> chaque vertex est transformé une fois
 
4) tu traçes les triangles du tableau de triangles, le triangle setup pioche dans le tableau des vertexs transformés.
et le triangle et traçé (par lignes horizontales)
 
l'approche d'un gpu:
 
1) tu as le tableau source de vertexs non transformés
2) pour chaque triangle du tableau de triangle (en fait c'est un tableau d'indexes), si les vertexs nécessaires ne sont pas en cache Post-T&L, les vertexs nécessaires sont chargés, puis transformés et mis dans le cache Post-T&l, le triangle setup se sert dans la cache.
 
=> si des triangles consécutifs partagent le même vertex il est réutilisé depuis le cache (interne au gpu).
=> du coup un vertex peut être tranformés plusieurs fois pour la même frame de la scène.
=> le gpu ne fait que "lire" les vertexs, toutes les écritures de vertexs transformés se font dans un (petit) cache interne.  
 
et puis on traçe le triangle ligne par ligne horizontale.