Ce forum est maintenant fermé, seule cette archive statique reste consultable.
 Page :   1  2  3
Page Suivante
Auteur Sujet :

[Article] - Architecture et fonctionnement d'un GPU

n°12397
Ashe
reenignE esreveR
Posté le 26-06-2005 à 17:36:49  
 

Reprise du message précédent :
T'affiches avec quoi? glBegin/glEnd, vertex arrays, vertex arrays compilées, VBO?
Edit: et ton idée à l'arrache dépend de ce qu'il y a derriere la caméra, mais en général ca se fait avec un quadtree


Message édité par Ashe le 26-06-2005 à 17:37:21

---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
mood
Pub
Posté le 26-06-2005 à 17:36:49  
 

n°12445
requiem13
Posté le 27-06-2005 à 12:32:55  
 

c'est du glBegin/glEnd compilé dans une liste openGL.
c est vrai qu il faut que je teste avec des arrays ca reduit considérablement le nombre de vertex.
 
j ai placé la camera sur le joueur en vue subjective (a la quake).
 
Ok pour le quadtree mais c un niveau au dessus de la couche opengl ca.
Ca me sera toujours utile pour ameliorer mes tests de collision.
 
merci ;)
 
ps : VBO c'est quoi donc ? B)

n°12454
lordbubu
stop au célibat->en recherche
Posté le 27-06-2005 à 16:27:03  
 

J'ai trouver la deuxième partie moins jargon, mais bon ça viens peut du fait que après avoir vu au moins 5 fois la 1ere partie, j'ai mieux pigé la seconde.
En tout cas mainteant dans les options de ma CG je cliquerai plus sur toutes les options sans savoir à quoi ça sert.
 
Je cliquerais sur toute les options en SACHANT à quoi ça sert.(enfin presque)
 
Sinon super article Ashe, du bon boulot.
 
Allez maintenant au boulot la même pour les cartes son ;)

n°12456
Ashe
reenignE esreveR
Posté le 27-06-2005 à 16:46:25  
 

requiem13 a écrit :

c'est du glBegin/glEnd compilé dans une liste openGL.
c est vrai qu il faut que je teste avec des arrays ca reduit considérablement le nombre de vertex.


En fait non, ca reduirait juste le nombre d'appels de fonction (vu que t'aurais pas 5000 glVertex/glColor/glNormal/etc)

Citation :

Ok pour le quadtree mais c un niveau au dessus de la couche opengl ca.


Si OpenGL faisait tout y aurai plus rien a programmer

Citation :

ps : VBO c'est quoi donc ? B)


Euh, les vertex buffer objects
En fait y a les glBegin que tu fais, puis y a les vertex arrays (OpenGL 1.1 si jme souviens bien), les compiled vertex arrays (qui n'apportent rien, sauf si tu as plusieurs passes), puis nVIDIA et ATI ont des extensions propriétaires (NV_vertex_array_range, NV_fence, par exemple), puis maintenant y a ARB_vertex_buffer_object qui est standardisé et qui marche partout (enfin, quand le pilote le supporte
Par ici pour la doc : http://oss.sgi.com/projects/ogl-sa [...] object.txt
Ca permet d'allouer la mémoire directement dans la carte graphique, des trucs comme ca [:spamafote]
Sinon pour reduire le nombre de vertices, il faut utiliser un index buffer (qui peut etre alloué avec ARB_vertex_buffer_object aussi)

n°12475
lecknaat
Posté le 27-06-2005 à 21:57:34  
 

Beau travail !

n°12477
requiem13
Posté le 28-06-2005 à 00:33:06  
 

Merci Ashe pour les VBO, je vais etudier ca, ca a l air bien foutu ;)
 
ps : j arrete de flooder ce topic et je te contacterai par mail si besoins.

n°12885
loni
Posté le 19-07-2005 à 18:25:29  
 

En tant que mon tout premier mail sur ce site (qui a motivé mon inscription), je tiens à te féliciter (Ashe) pour la qualité de ton article qui a su présenter (malgré le jargon parfois barbare mais juste) le pourquoi du comment de nos chères petites locataires du (Ô-magique) port AGP.
 
Amateur du dimanche soir de la modélisation 3d (via 3dsmax), j'ai pu retrouver pas mal d'objets et de techniques dont tu parlais et j'invite quiconque ayant la motivation et la patience d'en savoir plus sur ces concepts flous en apparence (tels que les primitives, l'anti-aliasing, le filtre anisotrope, le canal alpha....) de toucher et bidouiller un chouia ce genre de softs (attention, QUE DES ORIGINAUX HEIN!!), pour voir EN CLAIR de quoi il s'agit lorqu'on travaille avec.
 
Si j'ai le temps, je posterai peut-être un jour un topic pour parfaire modestement ton article en "vulgarisant" au plus simple les différentes notions que tu as evoquées pour satisfaire les plus paresseux que nous sommes tous quelquepart. Non? Ah bon...
 
Encore BRAVO !!!  Et ne perds pas la patte ;)


Message édité par loni le 20-07-2005 à 18:29:35

---------------
Certitude, servitude...
n°13258
Yasko
Posté le 31-07-2005 à 21:23:58  
 

Bon, j'arrive un peu tard, mais je pose ma question quand même (oui, qu'une seule cette fois) :)  
 

Citation :

Le test de profondeur permet surtout de ne pas avoir à afficher les pixels qui ne seront pas visibles.


 
Ce n'est pas déja fait lors des étapes de culling et de clipping ? (pixels supprimés par suppression des vertex).
D'un autre coté, comment la transparence est gérée si le clipping ne conserve que le vertex le plus proche d'un même couple X,Y ?
Les surfaces qui peuvent être "clipper" ou "clippantes" sont à déclarer explicitement ?


Message édité par Yasko le 01-08-2005 à 09:58:36
n°13269
Ashe
reenignE esreveR
Posté le 01-08-2005 à 10:05:19  
 

Le clipping est surtout pour ce qui est "hors" de l'ecran (genre ce qui est derriere ton personnage), quand je dis ne pas afficher les pixels qui ne seront pas visibles, c'est parce qu'ils seraient caches par un pixel qui se trouve dans la meme trajectoire mais plus proche (donc "devant" le nouveau pixel)


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°13270
Ashe
reenignE esreveR
Posté le 01-08-2005 à 10:05:46  
 

(et ce n'est pas explicite, c'est un simple calcul)


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°13277
Yasko
Posté le 01-08-2005 à 11:58:38  
 

Ashe a écrit :

Le clipping est surtout pour ce qui est "hors" de l'ecran (genre ce qui est derriere ton personnage), quand je dis ne pas afficher les pixels qui ne seront pas visibles, c'est parce qu'ils seraient caches par un pixel qui se trouve dans la meme trajectoire mais plus proche (donc "devant" le nouveau pixel)


 
D'où ma question sur la transparence :

Citation :

comment la transparence est gérée si le clipping ne conserve que le vertex le plus proche d'un même couple X,Y ?


n°13278
Ashe
reenignE esreveR
Posté le 01-08-2005 à 12:03:53  
 

Le clipping s'en fout qu'il y ait un pixel devant un autre, il se base juste sur la position du vertex
Le depth test se base sur la profondeur du pixel a afficher et celle du pixel present dans le Z-buffer, apres il suffit de choisir la methode de comparaison des valeurs (genre ca passe si c'est plus grand que, etc)
Pour la transparence, en general le depth test (ce qui fait cette comparaison) est desactive et les primitives sont triees avant d'etre affichees pour pouvoir etre affichees de la plus profonde a la plus proche [:spamafote]


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°13280
Yasko
Posté le 01-08-2005 à 12:22:24  
 

Ashe a écrit :

Le clipping s'en fout qu'il y ait un pixel devant un autre, il se base juste sur la position du vertex


 
Oui, le clipping travaille sur les vertex, mais le fait que le clipping supprime les vertex masqués par d'autres plus proches n'a pas pour conséquence de supprimer également les pixels qui auraient été placés lors du tramage dans ces vertex ? (équivalence suppression vertex => suppression pixels dans vertex)

n°13281
Ashe
reenignE esreveR
Posté le 01-08-2005 à 13:06:10  
 

Bon, jvais essayer de faire encore plus simple :p
 
T'es dans Doom
Ton perso regarde vers le nord (bien droit), devant lui y a une porte. Sur cette porte y a un panneau...
 
Tout ce qui est pile au dessus de lui, pile en dessous de lui, derriere (bref, ce qui est pas dans l'angle de vue), c'est le clipping qui le "coupe", et c'est pas affiche (meme si dans la pratique c'est au niveau logiciel que ca s'fait et pas materiel, mais c'est pour l'exemple)
 
Ce qui est derriere la porte peut etre coupe par le clipping, mais ca n'arrive jamais et c'est fait au niveau logiciel (genre la porte c'est un "portal", elle est fermee donc on voit pas cki a derriere, donc le rendu s'arrete a la porte quand on traverse le scenegraph)
 
Maintenant le panneau... ben lui il va etre affiche avant la porte... les pixels qui sont utilises pour le dessiner sont envoyes vers le framebuffer (c'est simplifie encore une fois) au niveau de la couleur, et leur profondeur va dans le z buffer. APRES, on affiche la porte. Tous les pixels de la porte sont envoyes vers le framebuffer sauf ceux qui sont "derriere" le panneau, puisqu'ils sont caches par celui ci (chose que la carte sait avec le depth test, c'est a dire comparer la profondeur du nouveau pixel avec celle de l'ancien pixel).
 
Voila, j'pense pas que je peux faire plus simple [:spamafote]


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°13282
Yasko
Posté le 01-08-2005 à 13:47:51  
 

Citation :

Ce qui est derriere la porte peut etre coupe par le clipping


Oui, c'est bien de ça dont je veux parler (pas de ce qui n'est pas dans le champ de vision).
 

Citation :

mais ca n'arrive jamais et c'est fait au niveau logiciel


Au niveau de DirectX / OpenGL ? Le rendu de la scène est limitée au plan de la porte ? Seuls les vertex présents avant le plan de la porte sont transmis au GPU ?
Je te propose un autre exemple :
Le personnage est face à 2 cubes C1 et C2, il n'y a pas de plan ou arrêter la scène (mur, porte, ...), les 3 éléments sont alignés sur une même droite, C1 est devant C2, et la taille de C1 et de C2 est telle que C2 est complétement masqué par C1.
Est-ce que le clipping supprime les vertex de C2 ?
Ou est ce que ces vertex sont tramés, et leurs pixels ensuite éliminés par le test de profondeur ?


Message édité par Yasko le 01-08-2005 à 13:48:54
n°13285
Ashe
reenignE esreveR
Posté le 01-08-2005 à 14:10:59  
 

Yasko a écrit :


Au niveau de DirectX / OpenGL ? Le rendu de la scène est limitée au plan de la porte ? Seuls les vertex présents avant le plan de la porte sont transmis au GPU ?


Non, au niveau du code du jeu, y a une organisation hierarchique de tous les elements du niveau
 

Citation :

Est-ce que le clipping supprime les vertex de C2 ?


Non

Citation :

Ou est ce que ces vertex sont tramés, et leurs pixels ensuite éliminés par le test de profondeur ?


Oui (et il faut du coup afficher le cube le plus proche en premier, pour que ce soit utile)


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°13287
Yasko
Posté le 01-08-2005 à 15:34:52  
 

OK, Thx

n°17784
xh13
Posté le 30-07-2006 à 22:03:15  
 


J'aimerais que l'article soit beaucoup plus détaillé.
 
Personnellement, J'ai de beaucoup préféré la première partie à la seconde, qui ne fait qu'efleurer le sujet.
 
En particulier, il aurait été souhaitable que l'étape se déroulant entre les deux shaders, soit le tramage, soit expliquée dans tous ses mécanismes.
 
Ensuite, j'aurais aimé que la seconde partie sur les pixels shaders poursuive dans la même veine et selon le même modèle que la première partie sur les vertex shaders. Ainsi, il aurait été bien d'avoir un diagramme de l'architecture d'un pixel shader ainsi qu'une liste et une description des registres associés au pixel shader.
 
Très bon article tout de même. Il a le défaut de sa qualité, c'est-à-dire qu'il donne envie d'en savoir plus! Une liste de liens vers des articles plus détaillés à la fin du texte aurait facilité la tache de celui qui veut creuser le sujet.

n°17785
sebx
Posté le 30-07-2006 à 23:17:57  
 

- matbe ne fait plus que dans le hardware...
 
- t'as pas l'impression d'arriver après la guerre là ?  :D


---------------
matbe forever !
n°17786
murmex
Complication avant tout...
Posté le 31-07-2006 à 16:05:16  
 

sebx a écrit :

- matbe ne fait plus que dans le hardware...
 
- t'as pas l'impression d'arriver après la guerre là ?  :D


En meme temps si c'est pas du hardware comme article...

n°17827
Ashe
reenignE esreveR
Posté le 06-08-2006 à 01:42:32  
 

xh13 a écrit :

Ensuite, j'aurais aimé que la seconde partie sur les pixels shaders poursuive dans la même veine et selon le même modèle que la première partie sur les vertex shaders.


Justement, on m'a demande de faire la partie sur les pixel shaders differemment parce que la partie sur les vertex shaders etaient trop euh.. pas "grand public" :p


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°17829
EricTermin​ator
www.pcsilencieux.com
Posté le 06-08-2006 à 02:09:57  
 

Citation :

pas "grand public"


 
:ddr:

n°17830
Ashe
reenignE esreveR
Posté le 06-08-2006 à 10:27:02  
 

Hey waip, seules les personnes de petite taille comprenaient :o


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°17831
EricTermin​ator
www.pcsilencieux.com
Posté le 06-08-2006 à 13:22:51  
 

C'est bon, je fais dans les 1.70m ! :D

n°17832
Ashe
reenignE esreveR
Posté le 06-08-2006 à 16:50:48  
 

Quel talent :sol:


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°17833
EricTermin​ator
www.pcsilencieux.com
Posté le 07-08-2006 à 03:08:49  
 
n°17860
sadhiq
www.techactu.com
Posté le 08-08-2006 à 14:06:07  
 

très très intéressant, mais ca t'a mis combien de temps pour écrire tout ça? (j'ai pas encore tout finis de lire, donc j'essaye d'imaginer l'écrire :D )

n°17862
Ashe
reenignE esreveR
Posté le 08-08-2006 à 14:23:32  
 

3-4 heures
(avec de longues pauses :D)


Message édité par Ashe le 08-08-2006 à 14:23:45

---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°17957
metm
Posté le 23-08-2006 à 21:57:22  
 

Ashe c est quoi ta CG ????

n°17974
Ashe
reenignE esreveR
Posté le 26-08-2006 à 21:08:51  
 

La juste a la seconde une Radeon 9600 Pro


---------------
pcx360 | Binary Genetics | Dreaming Prophet
“Entropy isn’t what it used to be.”
n°24435
Davor
Posté le 11-05-2009 à 17:52:52  
 

Bonjour,
J'ai lu votre sympathique petit article...Mais j'ai un problème : je n'ai pas trouvé la réponse à ma question qui est : "Peut-on dire du GT200 qu'il s'agit d'un processeurs x86 ? "
 
Est-ce que par hasard vous auriez la réponse ?
 
Merci d'avance,
 
Salutations,
 
Davor

n°24436
fredo490
Mais pourquoi donc ?
Posté le 11-05-2009 à 18:28:28  
 

Davor a écrit :

Bonjour,
J'ai lu votre sympathique petit article...Mais j'ai un problème : je n'ai pas trouvé la réponse à ma question qui est : "Peut-on dire du GT200 qu'il s'agit d'un processeurs x86 ? "
 
Est-ce que par hasard vous auriez la réponse ?
 
Merci d'avance,
 
Salutations,
 
Davor


 
Je vois pas se que le GT200 a d'un processeur x86   [:dreamworker:4]  
 
Le seul GPU qui est "proche" d'un CPU est le Larrabee d'intel qui va sortir prochainement :
http://en.wikipedia.org/wiki/Larrabee_(GPU)


Message édité par fredo490 le 11-05-2009 à 18:28:43

---------------
Ha oui, c'est ici qu'on écrit notre signature.
 Page :   1  2  3
Page Suivante