L'AGP 8x est sorti, à quand les carte graphiques AGP 8x ??? - Hardware
Marsh Posté le 02-09-2002 à 23:42:06
bybul a écrit a écrit : voila, vous avez des infos ??? |
la powercolor SIS xabre400 testée sur clubic.com et notée 3/10 seulement
Marsh Posté le 02-09-2002 à 23:44:05
ben c'est inutile pour l'instant l'agp8x
Marsh Posté le 03-09-2002 à 00:25:15
nan c'est pas inutile, et la radeon 9700 pro est agp 8x
la future nv30 sera agp 8x
et il y aura ptet des version agp 8x des gf4.
Marsh Posté le 03-09-2002 à 00:48:27
bjone a écrit a écrit : nan c'est pas inutile, et la radeon 9700 pro est agp 8x la future nv30 sera agp 8x et il y aura ptet des version agp 8x des gf4. |
ah oui et à part niveau marketing quel est l'interet pratique?
Marsh Posté le 03-09-2002 à 00:51:07
une geforce 4 prends la pleine bande passante de l'agp 4x si le vertex buffer est ram agp et pas en ram vidéo.
il évident qu'une radeon 9700 qui a quasiment le double des perfs d'une gf4 en vertex/secs, as besoin d'un bus supérieur à l'agp 4x dans le cas de vertexbuffer en ram agp.
Marsh Posté le 03-09-2002 à 00:56:19
bjone a écrit a écrit : une geforce 4 prends la pleine bande passante de l'agp 4x si le vertex buffer est ram agp et pas en ram vidéo. il évident qu'une radeon 9700 qui a quasiment le double des perfs d'une gf4 en vertex/secs, as besoin d'un bus supérieur à l'agp 4x dans le cas de vertexbuffer en ram agp. |
si la carte passe en RAM AGP, les perfs s'effondrent de toute façon, que ça soit en AGP 4x ou en AGP 8x, donc aucun intéret
Marsh Posté le 03-09-2002 à 01:01:23
Oui pour les textures.
Non pour la géomtrie.
Tout l'intêret est de fournir le moteur géométrique via l'AGP, et les unités de texture par la ram vidéo.
L'agp 2X suffit à une Geforce 1/2, presque pour la 3.
L'agp 4X est nécessaire à la Geforce 4.
Il évident que la Radeon 9700 Pro et le NV30 tireront parti de l'agp 8X.
Ce qui maximise le rendement.
Marsh Posté le 03-09-2002 à 01:09:58
j'étais du même avis que mareek mais je dois avouer que ton explication semble tenir la route.
Marsh Posté le 03-09-2002 à 01:11:07
"La première mouture -utilisable- de l'AGP (Accelerated Graphics Port) offrait, en son temps, une bande passante de 533 Mo/s avant d'être remplacée par l'AGP 4X qui offre pour sa part une bande passante de 1066 Mo/s. Conçu à l'origine pour remplacer le vieillissant bus PCI et son débit maximal de 133Mo/s qui pénalisait de manière assez importante les performances des cartes graphiques 3D, il est vrai que l'AGP 4X arrive à devenir pour certains jeux ultra récents comme Unreal Tournament 2003 une sorte de goulet d'étranglement en particulier si la mémoire de la carte graphique n'abonde plus. Rappelons que la carte graphique utilise au maximum sa propre mémoire pour stocker les textures afin de garantir un temps de traitement optimal mais devra utiliser la mémoire système en cas d'engorgement d'où l'importance de la rapidité du bus. En toute logique l'AGP 8X double la bande passante de l'AGP 4X et délivre donc une bande passante mémoire de 2132Mo/s pour une fréquence de 533MHz, ce qui s'avèrera amplement suffisant pour les prochains quake like et autre doom 3 d'autant que dans le même temps la quantité de mémoire intégrée sur les cartes graphiques augmentera encore, réduisant de ce fait le recours à l'échange de données entre la carte graphique et la mémoire système. Du coup l'AGP 8.0X pourrait bien s'avérer être une non révolution si l'on considère le fait qu'actuellement très peu de jeux utilisent plus de 64MO de mémoire vidéo. Seules les cartes d'entrée de gamme devraient tirer un léger profit de l'AGP 8.0X du fait de leur quantité de mémoire généralement limité, ce que nous vérifierons dans ce test. "
Source: http://www.clubic.com/ar/gen/1470-2.html
Marsh Posté le 03-09-2002 à 01:12:04
malgré tout ce que l'on peut croire, toute techno a une raison d'être....
(en général)
Marsh Posté le 03-09-2002 à 01:20:45
johnbroot a écrit a écrit : j'étais du même avis que mareek mais je dois avouer que ton explication semble tenir la route. |
+1
(heureusement que j'étais du même avis que moi quand même
Marsh Posté le 03-09-2002 à 01:23:01
Le monsieur qui a écrit ça chez Clubic a downloadé le SDK du Dx8 ou code en OpenGL pour avoir une idée de ce qu'il raconte ?
Ta carte 3D, si l'on raisonne en Direct3D, à trois ressources principales:
Les Textures
Les VertexBuffers
Les IndexBuffers
Les textures tout le monde sait ce que c'est.
Les vertexbuffers et les indexbuffers décrive, ce que l'on appelle communément -la géométrie-.
Contrairement à ce que l'on pense cette géométrie représente une bande-passante palpable.
Il y a tout interêt au niveau de la carte 3D, de "charger" cette géométrie par l'AGP, pendant que les unitées de textures utilisent la RAM vidéo pour charger les pixels des texures.
Ce qui permet d'offrir TOUTE la bande-passante mémoire aux unitées de textures qui sont affreusement gourmande en bande-passante... (et zou de l'anisotropicetzoudu fsaa..)
L'Agp 4X suffit mais est quand-même nécessaire à une Geforce 4, pour quelle atteingne son débit maximal en Vertexs/Seconde.
Vu les performances théoriques de la Radeon 9700 PRO, l'Agp 8X devrait s'avérer une obligation pour être à plein rendement pour une application à géométrie intense.
Après il faut voir les stratégies sélectionnées par le driver, si le vertexbuffer est mis en ram vidéo ou en ram agp.
Marsh Posté le 03-09-2002 à 01:23:53
bjone a écrit a écrit : Le monsieur qui a écrit ça chez Clubic a downloadé le SDK du Dx8 ou code en OpenGL pour avoir une idée de ce qu'il raconte ? |
Pkoi tu prends ça autant à coeur ???
Marsh Posté le 03-09-2002 à 01:24:58
ouééééééééé
je suis po content
Marsh Posté le 03-09-2002 à 01:33:24
bjone a écrit a écrit : malgré tout ce que l'on peut croire, toute techno a une raison d'être.... (en général) |
en fait j'ai été induit en erreur par ces article:
http://www.onversity.com/cgi-bin/p [...] 200205#100
http://www.onversity.com/cgi-bin/p [...] 200207#010
merci barbarella
Marsh Posté le 03-09-2002 à 01:38:31
vi il dit des bêtes là le monsieur...
ce n'est PAS le cpu qui traite la géométrie...
Marsh Posté le 03-09-2002 à 01:43:38
bjone a écrit a écrit : vi il dit des bêtes là le monsieur... ce n'est PAS le cpu qui traite la géométrie... |
ben en partie quand même (pour tout ce qui est test de collision par ex. il a besoin de la géométrie)
Marsh Posté le 03-09-2002 à 01:47:16
souvent ce n'est pas la même, le niveau de détail est plus bas ou on se contente de bounding-box.
et si on désire descendre au niveau triangle, on utilise des algos dégrossif (bounding box perso->bounding box jambe->tests triangles tibia ) , ce qui fait que le cpu ne teste qu'une poignée de triangles sur les millions de triangles des scènes que pourront faire les jeux futurs....
Marsh Posté le 03-09-2002 à 01:53:06
et d'ailleurs ce ne seront les mêmes données données qui seront utilisées par le gpu pour le traçage et le cpu pour les tests de collision...
dans l'indexbuffer par triangle:
3 indexs par triangle (qui indique quels vertexs à utiliser dans le vertexbuffer)
ça peut être moins si c'est des strips
dans le vertex buffer, par vertex
coordoonnées spaciales x,y,z
vecteur normal pour l'ombrage de gouraud nx,ny,nz
coordoonées textures u,v
& + si affinitées (un vecteur de + pour faire le bumpmapping par dot3)
pour les tests de collisions, on pense plus "équation de plan".
donc tu auras de toutes manières deux blocs de données différents pour la même géométrie, un pour le gpu, un pour le cpu pour ses tests de collisions.
Marsh Posté le 03-09-2002 à 02:01:41
bjone a écrit a écrit : et d'ailleurs ce ne seront les mêmes données données qui seront utilisées par le gpu pour le traçage et le cpu pour les tests de collision... dans l'indexbuffer par triangle: 3 indexs par triangle (qui indique quels vertexs à utiliser dans le vertexbuffer) ça peut être moins si c'est des strips dans le vertex buffer, par vertex coordoonnées spaciales x,y,z vecteur normal pour l'ombrage de gouraud nx,ny,nz coordoonées textures u,v & + si affinitées (un vecteur de + pour faire le bumpmapping par dot3) pour les tests de collisions, on pense plus "équation de plan". donc tu auras de toutes manières deux blocs de données différents pour la même géométrie, un pour le gpu, un pour le cpu pour ses tests de collisions. |
merci, je m'endormirais moins con ce soir.
Marsh Posté le 03-09-2002 à 07:52:26
et en ce moment alors, il vaut mieux acheter une cartre AGP 4x ou une AGP 8x (je comptai aussi acheter une GF4 Ti4200 128 Mo)
mais donc, apparement, au pus il y a de memoire, au moins on s'en sert de l'AGP 8x ...
Marsh Posté le 03-09-2002 à 12:32:05
bjone a écrit a écrit : vi il dit des bêtes là le monsieur... ce n'est PAS le cpu qui traite la géométrie... |
c'est faux. la géométrie de base est entièrement traitée par le CPU, seules les tranformations géométrique se font sur le GpU a présent. Mais la position de tous les modèles c'est le CPU, quand un perso lève le bras c'est le CPU, quand tu casses un objet c'est la CPU, quand tu déplaces un objets c'est le CPU, etc ...
Marsh Posté le 03-09-2002 à 12:35:18
mareek a écrit a écrit : en fait j'ai été induit en erreur par ces article: http://www.onversity.com/cgi-bin/p [...] 200205#100 http://www.onversity.com/cgi-bin/p [...] 200207#010 merci barbarella |
ou il est le prob. je dis en gros dans ces 2 mini-articles, que c'est les transferts de la géométrie du cpu vers le processeur graphique qui sont le plus utile pour l'AGP. Donc plus un jeu exploitera les vertex shader, plus il aura beson d'un AGP rapide, evidement dans la mesure ou la CG le supporte les vertex et en fonction de sa vitesse a les traiter.
Marsh Posté le 03-09-2002 à 12:37:52
il n'y a déja pas de diff notable de perf entre agp 2x et 4x
alors c'est pas le 8x qui va multiplier par 2 les perfs
Marsh Posté le 03-09-2002 à 13:57:48
barbarella a écrit a écrit : c'est faux. la géométrie de base est entièrement traitée par le CPU, seules les tranformations géométrique se font sur le GpU a présent. Mais la position de tous les modèles c'est le CPU, quand un perso lève le bras c'est le CPU, quand tu casses un objet c'est la CPU, quand tu déplaces un objets c'est le CPU, etc ... |
oui mais, le temps cpu est relativement -ridicule- devant le temps gpu.
tu vas pas me faire que parceque au niveau cpu t'as quatre matrice 4x4 qui tu multiplies ça une importance devant le temps que mets le gpu à appliquer la matrice finale sur 2000 vertices.
de plus le gpu fonctionne indépendamment du cpu, il va chercher ses vertices dans la ram agp (ou vidéo), par l'agp, sans passer à aucuns moment par le cpu.
c'est d'ailleurs tout l'intêret du GART, que tu décris sans jamais le citer, comme inutilement compliqué, ce qui est faux.
de plus faire transiter le géométrie par l'agp est utilisé depuis la geforce 1, avec 3dmark 2000 on peut mesurer une division par deux des triangles/secs avec l'agp 1x par rapport à l'agp 2x.
le cpu ne fait que dire "traite ce bloc de 1000 vertices à l'adresse truc", et le gpu éxécute et donc le cpu n'a plus aucunes influances pendant le traitement du gpu.
ensuite ça dépends des moteurs.
un jeu de bagnole/avion aura un maximum de rendement et d'indépendance cpu pour le traçage des avions et des bagnoles.
la dépendance cpu augmentera le moteur de terrain pour le simu, et la gestion du circuit pour le jeu de bagnole.
les quake-likes actuels sont encore relativement dépendant du cpu, du au fait qu'il faut se balader dans l'arbre bsp pour le rendu (mais y'a beaucoup de chances qu'il y ait de la display list ou des vertex array qui ne sont refait que lorsque l'on change de secteur/salle).
Marsh Posté le 03-09-2002 à 13:59:54
lolo92 a écrit a écrit : il n'y a déja pas de diff notable de perf entre agp 2x et 4x alors c'est pas le 8x qui va multiplier par 2 les perfs |
le but d'augmenter les perfs de l'agp n'est pas d'augmenter les perfs des solutions d'accélération 3D matérielles existantes, mais de permettre aux solutions futures de continuer à évoluer sans avoir à rentrer dans un goulot d'étranglement.
Marsh Posté le 03-09-2002 à 14:03:02
lolo92 a écrit a écrit : il n'y a déja pas de diff notable de perf entre agp 2x et 4x alors c'est pas le 8x qui va multiplier par 2 les perfs |
Fait le test Vertex Shader de 3D Mark 2001 en 2x puis en 4x sur une GF4 tu verra
Marsh Posté le 03-09-2002 à 14:19:38
bjone a écrit a écrit : oui mais, le temps cpu est relativement -ridicule- devant le temps gpu. tu vas pas me faire que parceque au niveau cpu t'as quatre matrice 4x4 qui tu multiplies ça une importance devant le temps que mets le gpu à appliquer la matrice finale sur 2000 vertices. de plus le gpu fonctionne indépendamment du cpu, il va chercher ses vertices dans la ram agp (ou vidéo), par l'agp, sans passer à aucuns moment par le cpu. c'est d'ailleurs tout l'intêret du GART, que tu décris sans jamais le citer, comme inutilement compliqué, ce qui est faux. de plus faire transiter le géométrie par l'agp est utilisé depuis la geforce 1, avec 3dmark 2000 on peut mesurer une division par deux des triangles/secs avec l'agp 1x par rapport à l'agp 2x. le cpu ne fait que dire "traite ce bloc de 1000 vertices à l'adresse truc", et le gpu éxécute et donc le cpu n'a plus aucunes influances pendant le traitement du gpu. ensuite ça dépends des moteurs. un jeu de bagnole/avion aura un maximum de rendement et d'indépendance cpu pour le traçage des avions et des bagnoles. la dépendance cpu augmentera le moteur de terrain pour le simu, et la gestion du circuit pour le jeu de bagnole. les quake-likes actuels sont encore relativement dépendant du cpu, du au fait qu'il faut se balader dans l'arbre bsp pour le rendu (mais y'a beaucoup de chances qu'il y ait de la display list ou des vertex array qui ne sont refait que lorsque l'on change de secteur/salle). |
Bjone, n'essaye pas de me faire prendre des cerises pour des mirablelles . les jeux sont de plus en plus dependant du CPU, parceque l'a géométrie de base augmente et que celle-ci est avant tout traiter par le CPU.
Quant aux accès AGP directes en mémoire, faut rester sérieux, les accès ne se font pas dans un cadre temps réel mais en différé. Ce n'est que les informations situés en mémoire CG qui permettent le tps réel. Tel que tu le décrits on a l'impression que le proc graphique charge directement ses unités de traitement a partir de la mémoire. Non, on passe d'abord par la mémoire de la CG. C'est un principe semblable au prefetching des microprocesseur avec leur mémoire cache. De toutes manière il n'y a pas d'accès directe du proc vers la mémoire, car le mode DIME n'est plus exploiter.
Pour finir, tu nous sors des tas de connaissances, c'est chouette, mais tu veux en venir ou ? c'est quoi ton cheval de bataille, moi a travers mes 2 articles c'était de signifier qu'une partie des mécanismes qui était a l'origine de l'AGP n'ont plus d'interet aujourd'hui. L'augmentaiton conséquente de la mémoire embarqué sur les CG en témoigne alors qu'on nous promettais l'inverse (du moins pas une inflation de cette sorte).
Marsh Posté le 03-09-2002 à 14:20:43
oups
Marsh Posté le 03-09-2002 à 14:29:39
je suis pas d'accord.
1) observe le comportement géométrique d'une geforce 4 entre l'agp 2x et 4x et tu verras que l'agp 8x est nécessaire (pour l'après gf4 immédiat).
bon ça c'est pour le début du topic.
2) ensuite pour le GART et le mode DIME, c'est faux il est toujours utilisé. pas quand tu est sous le bureau, là c'est le mode DMA, mais quand une appli D3D ou OGL part, et que le programmeur à fait attention à utiliser positivement les bonnes extension, le mode DIME peut être utilisé par charger les vertexs par l'agp sans passer par la ram vidéo.
évidemment la stratégie entre le transfert des vertex par l'agp ou le stockage en ram est à la charge du driver, mais c'est simple si la géométrie est chargé par l'agp (le passage par la ram est inutile), toute la bande passante mémoire vidéo est allouée aux unitées de textures...
Marsh Posté le 03-09-2002 à 14:35:47
bjone a écrit a écrit : je suis pas d'accord. 1) observe le comportement géométrique d'une geforce 4 entre l'agp 2x et 4x et tu verras que l'agp 8x est nécessaire (pour l'après gf4 immédiat). bon ça c'est pour le début du topic. |
A ce propos.
Contrairement au GF4, les R8500 & co semblent être moins dépendantes de la vitesse de l'AGP ... je ne sais tjs pas d'ou ca vient.
Genre dans le test Vertex Shader de 3D Mark 2001, les performances s'effondrent sur GF4 si on passe en 2x voir 1x, et pas chez ATI.
Marsh Posté le 03-09-2002 à 14:37:48
justement ptet que les vertexs buffers sont mis en ram vidéo par le driver....
après fo voar l'adéquation...
Marsh Posté le 03-09-2002 à 15:09:59
par contre je viens de m'aperçevoir d'un truc en lisant une doc chez nvidia, les espaces mémoires verrouillées pour le mode DIME par le gart de l'agp, ne sont plus "swappables" par le noyau de Windows (ce qui est logique car les accès mémoire via le gart ne remontent pas au niveau cpu).
Marsh Posté le 03-09-2002 à 15:24:30
bjone a écrit a écrit : je suis pas d'accord. 1) observe le comportement géométrique d'une geforce 4 entre l'agp 2x et 4x et tu verras que l'agp 8x est nécessaire (pour l'après gf4 immédiat). bon ça c'est pour le début du topic. 2) ensuite pour le GART et le mode DIME, c'est faux il est toujours utilisé. pas quand tu est sous le bureau, là c'est le mode DMA, mais quand une appli D3D ou OGL part, et que le programmeur à fait attention à utiliser positivement les bonnes extension, le mode DIME peut être utilisé par charger les vertexs par l'agp sans passer par la ram vidéo. évidemment la stratégie entre le transfert des vertex par l'agp ou le stockage en ram est à la charge du driver, mais c'est simple si la géométrie est chargé par l'agp (le passage par la ram est inutile), toute la bande passante mémoire vidéo est allouée aux unitées de textures... |
Bjone tu m'agaces, parceque t'es partie dans une direction que je ne vois pas du tout. Tu contre-argumentes sur des arguments, mais on ne sait pas du tout ou tu veux aller. Des arguments c'est bien mais faut que ça soutienne une idée, c'est quoi ton idée finale. L'agp c'est pourri, l'agp c'est bien, l'agp comme il est c'est super, c'est a chié, blabla ... c'est quoi le fond de ton propos ?
En plus pour le 1) on pense exactement la meme chose et c'est exactement ce que j'ai dans mes articles.
pour le 2) alors là tu m'apprends un truc, tu es en train de me dire qu'il est possible de passer du mode DMA a DIME a la volée, c'est ça ? (donc sans redémarrer l'OS, la carte etc ...) si c'est ça alors effectivement ça je ne le savais pas.
Marsh Posté le 03-09-2002 à 15:31:17
Marc a écrit a écrit : A ce propos. Contrairement au GF4, les R8500 & co semblent être moins dépendantes de la vitesse de l'AGP ... je ne sais tjs pas d'ou ca vient. Genre dans le test Vertex Shader de 3D Mark 2001, les performances s'effondrent sur GF4 si on passe en 2x voir 1x, et pas chez ATI. |
salut marc,
c'est peut-être un début de réponse dans mon désaccord avec bjone. s'il se base sur son exprience sur nvidia et moi sur ATI, et que ces 2 constructeurs exploitent différement les possiblités AGP, alors effectivement ... faut voir.
Marsh Posté le 02-09-2002 à 23:38:14
voila, vous avez des infos ???