Reprise du message précédent :
moi je suis d'accord que le logiciel devrait pas planter (c des vilains chez Modelsim !). Apres la simu en swap disque c hors de question. Deja sur une machine performante, ca prends 5-6 min a chaque fois (et je fais ca a repetition), si ca swape sur le disque je prefere pas imaginer. Un autre logiciel (Xilinx ISE) qui calcule un circuit numerique (a programmer dans un FPGA) a partir de code VHDL ou Verilog vient de me dire que justement je manquais de memoire (RAM ou swap) et qu'il fallait en ajouter. Pour ce soft la, c carrement 30min par compilation de circuit quand ca swappe pas, alors la si ca devait swapper, ca serait la cata, ce soft la aussi je le fais tourner de nombreuses fois par jour !
Si vous voulez j'ai encore pas mal d'autres exemple, comme par exemple la comparaison de donnees tirees de notre produit (qui fait du rendu volumique et sort des donnees de 1 ou 2Go). Comparer 2 donnees de 2Go chacune, ca demande en toute logique 4Go (enfin c comme ca que mon humble softeux de service a implemnte ca dans son petit test qui verifie que ca marche ou pas) et c'est pour ca qu'on fait nos tests sur des donnees de seulement 1Go.

bref non, 4Go de RAM ne servent pas a rien pour tout le monde. Si vous tenez a le dire quand meme, il faut preciser que ca sert a rien pour faire de la bureautique et du jeu. Pour ceux qui font de l edition video, c autre chose deja. Et pour ceux qui font de la CAO comme moi, la c clair que les 4Go peuvent servir souvent.

Ah mais j'ai pas dit que ça servait pas hein, juste que ça sert à rien sous un NT x86
 
Si AMD a damé le pion à Intel sur le 64bits c'était justement car ça devient vraiment critique cette limite de 4Go proposée par le 32bits, le mode PAE étant pour sa part carrément médiocre...
 
Là où pour gérer plus de 2Go par processus il fallait perdre au choix du temps ou de la sécurité, la limite se voit repoussée sans "bidouillage". Ca a été testé sur des serveurs traitant typiquement des données en très grand volume (2Go c'est de la gnognotte à côté ), le gain était colossal.
 
D'ailleurs on peut noter que les 2Go sont artificiels déjà, vu que sur un bus 32bits on peut arriver à 4Gmots soit 16 à 64Go (32 à 128bits).

c'est justement ça, le PAE, 4G mots de 64bits (le PAE vient du pentioum 1 pro )
 
en fait ils ont fait comme le 68000 (qui adresse 32bits, 24bits cablés, mais 23 lignes de mots de 16bits avec un lo/hi) mais en conservant le bus 32 lignes
 
problème: coté logiciel tu adresse en octets, donc 4Go au mieuxe.

Ca explique donc la lenteur, puisque là où on ne devrait mettre qu'un cycle on en met 2 du coup...
 
C'était le 8088 qui avait inauguré ça il me semble, bus d'adresses 16bits interne mais 8bits externe, ce qui a mené à la pagination mémoire qu'on a trainé jusqu'aux noyaux NT...

pour le 68000 oui (sinon je me suis mal exprimé) / enfin je veux dire le 68000 mettais deux cycles données pour un mot de 32bits.
pour nos x86 actuels, rien à voir.
 
--
 
bah le PAE n'est pas un mal en lui-même (y'a d'autres features qui sont utiles)
après juste utilisé pour l'extension de l'adressage à la sauce emm386, c'est bof c'est sûr.
 
--
 
sinon le découplage interne/externe n'est pas un problème c'est juste une question rapport perf/prix (ou pas). (disons que le hardware peut être multiplexé sans implications logicielles derrière).
 
par exemple si tu causes avec un périphérique PCI-like, que le bus soit 32bits, 64bits ou sérialisé en PCIe tu t'en fous.  
si t'a besoin de faire un adressage 64bits sur un périph en PCI 32bits, ça prends 2 cycles mais comme le PCI est déjà multiplexé, ça reste insignifiant
 
par contre ce qui ne sera pas insignifiant, c'est tous les fabricants qui ont fait des périphériques PCI ne gèrant pas l'adressage 64bit et obligeant l'os a ramener ses buffers dans un espace adressable par le périph.
 
enfin on dévie là.... (my bad)

ca devie mais comme vous deviez dans mon domaine de predilection (le PCI, PCI-X et PCIe), je ne peux m'empecher de rajouter un petit mot   .

Dans les specs PCI-X c bien marque qu'il est obligatoire de gerer l'adressage 64b (mais pas dans les specs PCI par contre), c a dire que le periph doit avoir ses registres BAR d'une largeur de 64b pour que le systeme puisse assigner a ce periph un espace memoire situe au dessus de la limite des 4Go imposee par les adresses 32b.

J'ai moi meme voulu tester le periph PCI-X que je developpais il y a pas longtemps pour voir s'il fonctionnait lorsqu'il etait mappe au dela de 4Go (donc sur une adresse 64b qui demande deux cycles d'adresse sur un bus PCI-X de 32b ou encore 1 seul avec un bus 64b).

J'ai eu beau utiliser Windows XP 64b avec un Xeon recent mais c le bios qui assigne les espaces memoire aux peripheriques et il semble impossible qu'il mappe les periphs PCI (ou X ou Express) au dessus de 4Go.

En effet, j'ai essaye de grossir expres l'espace memoire PCI requis par ma carte jusqu'a 1Go, j'ai meme essaye de mettre 4 cartes  demandant chacune 512Mo ou meme 2Go et de mettre 6Go de RAM sur la machine de test mais ca n'a rien donne et a chaque fois le PC a carrement refuse de detecter mes peripheriques  lorsqu'il n'arrivait plus a les mapper sous 4Go.
Apres qques recherches, j'ai trouve que les chipsets et les bridges PCI (ou X ou Express) avaient la capacite de mapper les peripheriques au dela de 4Go mais que cette option etait plus ou moins complexe a utiliser (disons un tout petit peu) et qu'au final, aucun bios ne le permettait (les fabricants de bios sont des flemards ).

A mon avis et d'apres ce que j'ai pu trouver, le seul espace memoire pouvant etre mappe au dessus de 4Go est la memoire centrale du PC c a d la RAM.

Du coup, j'ai pu tester que ma carte PCI-X arrivait en tant que maitre a acceder a la RAM lorsque celle-ci etait mappee au dela de 4Go (j'ai bien vu les deux cycles d'adresse lorsque je testais sur un bus 32b) mais je n'ai jamais pu tester mon periph en tant qu'esclave situe au dessus de 4Go pour la simple raison que le bios n'a jamais voulu le mapper au dela de 4Go.

Les specs PCI-X disent pourtant que les periph PCI-X doivent pouvoir etre mappe au dela de 4Go (donc sur 64b) mais je n'ai pu le verifier qu'en simu et je suppose que c'est comme ca pour tout le monde (ou alors faut se refaire un bios juste pour ce test qui de ttes facons n'est pas tres important).

Meme si l'espace memoire mappe par les peripheriques PCI (ou X ou Express) est faible en general, il arrivera un jour ou les bios finiront par les mapper au dessus de 4Go (puisque c cense etre supporte par tous les periphs pcix et pcie). Et vu que comme moi, les autres n'ont pas du pouvoir tester le bon fonctionnement de leur periph mappe au dela de 64b sur un systeme reel, je me dis qu'on court a la cata... On est pas encore au bout de nos peines pour le passage a l'adressage sur 64b, y compris au niveau du hard !

Au niveau hard ça se contourne, il suffit d'ajouter un offset et d'utiliser une adresse 32bits (câbler les 32bits supérieurs quoi)

bien sur, c meme evident meme pour un ingenieur hard ce que tu dis ! Non seulement on ne cable pas les 64b d'adresses derriere mais au final on ne cable que ce qui est reellement utilise (logique), soit 24 bits dans mon cas puisque j'ai 16Mo de memoire a mapper par le PCI. Derriere je rajoute mon registre de selection de banque memoire qui fait 7b et j'obtiens une adresse de 31b qui me permet de mapper mes 2Go de memoire embarquee.
le probleme hard, s'il y en a, c tout simplement au niveau sequentiel, au niveau meme de l'interface PCI, puisqu'il nous arrive les 64b de l'adresse en 2 fois au lieu d'une pour du 32b, et il y a la possibilite d'avoir un cycle d'horloge en plus. La sequence (une machine d'etat) etant assez complexe tout de meme (c pas du soft !), un cycle d'horloge en plus peut tout chambouler. En hard, si ca marche avec une sequence precise (phase d'adresse de 1clk, phase d'attributs de 1clk, phase d'attente de x clks et phases de donnees de x clks), on ne peut pas etre sur a 100% que ca va marcher avec une autre sequence si on l'a pas testee, surtout au niveau de la phase d'adresse qui est tres sensible (bcp de signaux de controle qui changent d'etat...).
 
En PCIe c encore pire puisque ca decale tout le paquet recupere en serie...
 
Ca peut paraitre tres simple comme ca (ca l'est dans une certaine mesure), il n'empeche qu'une anomalie deja existante avant (un signal de controle qui arrive tard...) peut etre revelee par ex uniquement dans le cas des adresses 64b et tant qu'on aura pas fait le test dans ce cas la, on pourra difficilement etre sur a 100%. Le hard est dans un certain sens moins complexe (ne pas confondre avec complique) que le soft, mais contrairement au soft, il est malheureusement bcp moins facile a predire et ca provoque des migraines crois-moi !

Mais y'a pas une initialisation de registres "normalisée" à la phase d'initialisation?
 
Genre le PCI qui donne sa norme aux cartes de la même façon qu'on soit en PCI, PCI-X ou PCI-E et la carte qui s'auto-configure en fonction de ça et renvoie les infos de sa config au contrôleur de bus? (comme on fait un broadcast en bus de terrain/réseau pour demander qui est sur la ligne, ce qui entraine une réponse de tout le monde dans le désordre d'un retard aléatoire)

je vais pas faire un cours sur le PCI non plus mais je donne qques pistes quand meme, desole pour le HS complet et les explications compliquees et a ralonge.

Je t'avoue Gigathlon que je comprends pas tout ce que tu dis. Tout d'abord par rapport a ton parallele avec le reseau, disons que PCI et PCI-X sont un peut comme le protocle 10/100Mb et le protocole 1Gb. Apres ca s'arrete la pour la comparaison car le PCI et le PCI-X sont des protocoles ou tous les acces sont forcement broadcastes puisque le meme bus est partage par tout le monde (contraire de point a point).

En ce qui concerne le PCIe, le protocole n'a rien a voir et n'est pas compatible physiquement, sachant qu'en plus c'est un protocole point a point et serie cette fois.

Par contre, le PCI et le PCI-X etant compatibles vers le bas (on peut brancher une carte PCI sur un slot PCI-X mais pas le contraire par contre), le controleur de bus PCI-X verifie si tout le monde sur le bus est capable de tourner en PCI-X, a quelle frequence et avec quelle largeur de bus (si le bus est un bus 64b). Cette reconnaissance est faite grace a la detection d'une tension en point qui est a 0, 1/2 ou 1 selon que les cartes ont ce point relie direct a la masse (0 = PCI), relie a la masse via une resistance de 10k (1/2 = PCI-X 66MHz) ou flottant en cicruit ouvert (1 = PCI-X 133Mhz). Il existe un peu la meme technique pour la detection du bus 64b.

Apres ca, le bus choisit le protocole de sorte que tout le monde arrive a communiquer, sachant que ceux qui sont compatibles PCI-X sont forcement compatibles PCI mais ceux qui ont leur signal de protocole relie a la masse (PCI) ne fonctionnent qu'en PCI et pas en PCI-X. Il suffit donc d'une carte PCI melangee avec d'autres cartes PCI-X pour que le bus et les cartes PCI-X 133Mhz connectees avec se retrouvent a fonctionner en PCI 33MHz.

Si on est en PCI, il n'y aura pas de phase d'attributs qui n'existe qu'en PCI-X et les sequenceurs des periph PCI-X doivent fonctionner dans les deux cas. Ils doivent fonctionner aussi dans le cas du bus de donnees de 32b ou de 64b ainsi qu'ils doivent fonctionner dans le cas d'adresse de 32b ou d'adresses de 64b (qui demande le support du Dual Address Cycle si jamais le bus de donnees ne fait que 32b). Quand on teste si son circuit d'interface PCI marche, il faut tester toutes ces combinaisons puisque initialisation ou pas, les differentes possibilites sont toutes cablees puisqu'au final on n'a qu'un seul circuit electronique !

Apres pour ta question d'initialisation de registre, ca vient juste apres que chaque bridge aie determine dans quel protocole fonctionne son bus (PCI ou PCI-X pour les bus PCI-X, PCIe 1.0 ou 2.0 pour les bridges PCIe).
Il existe une petite zone de memoire appele zone de configuration PCI qui est commune cette fois a tous les protocoles PCI, y compris PCIe. En PCI-X ou en PCIe, cette zone sera etendue au moyen de pointeurs afin de donner des infos supplementaires sur les nvlles capacites liees au PCI-X ou au PCIe. Le systeme (le chipset et le bios donc) envoie des acces configuration en broadcast vers tous les bus qui eux meme traduisent dans le protocole de leur bus l'acces qu'ils envoient a leur tour a tous les periph sur leur bus.

C la que le chipset verifie qui est present sur quel bus, et entre autres quelle est la taille de(s) l'espace memoire que chacun requiert (il verifie les registres BAR ou Base Address Register donc qui se situent dans cet espace de configuration PCI). Une fois connue la demande de chacun, le bios assigne un intervalle de memoire pour chacun (enfin seulement pour ceux qui en demandent) selon un algorithme propre a chaque bios. Et ma constatation est que les bios actuels, du moins ceux que j'ai testes, n'assignent pas d'intervale au dessus de 4Go.

Pour conclure et pour essayer de repondre a ta question:

ma reponse est oui a haut niveau (bios, soft) et non a bas niveau (hard, circuit logique).
Y'a une initialisation normalisee du PCI vu par le bios et le chipset avec une zone de registres de config PCI commune a tous les protocoles PCI.

Mais reste qu'a un niveau plus bas, les protocoles sur chaque bus sont differents, et une carte qui peut fonctionner avec plusieurs protocoles (PCI ou PCI-X, PCIe adresse 32b ou PCIe adresse 64b) doit pouvoir switcher entre ces protocoles apres la phase d'initialisation.

Selon le protocole, la sequence est differente (sinon y'aurait pas plusieurs protocoles) et c a chacune de ces sequences que le periph doit pouvoir repondre correctement. Pour rappelle, un controleur PCI sur un peripherique n'est jamais que des portes logiques connectes entre elle avec un reset et cadencees par une clock. Pour les softeux tout ca est transparent, mais pour le hard, il faut que tout ca fonctionne et ca se fait pas automatiquement !

point très interressant.
 
si les chipsets actuels ne sont pas capable de mapper les périphériques (PCI) au dessus de 4Go, on peut effectivement faire une murale avec mettons juste un quad-sli de carte 3D de 1Go ou un sli de carte 3D de 2Go (ce qiu va arriver bientôt).
 
Alors par contre, justement nVidia commercialise des baies de rendu (Gelato) de Geforce 8 (Quadro), donc très rapidement ils ont dû avoir a faire des qualification de chipset/mobo pour.
 
Il serait interressant de voir jusqu'à combien de cartes ils peuvent mettre, quel espace ça consomme, et qu'est-ce qui marche bien avec (et qui chie dans la colle).
(à voir avec la stratégie de remapping que l'on utilise sur les mobos acutelles qui plaçent les périphs entre 2Go et 4Go. et la ram entre 0-2Go et 4Go+)

Ok, donc c'est bien du mamaillage, bravo le PCI-SIG
 
La logique voudrait qu'on broadcast le bus en mode "compatible" pour connaître les capacités des périphériques avant de les initialiser (lecture d'un registre et écriture d'un autre quand tous les périphs ont répondu), c'est encore au stade des jumpers actuellement
 
Ceci dit, même avec la méthode "à l'ancienne" on devrait pouvoir sous-utiliser le bus pour un seul périphérique en omettant le 2e cycle d'adressage dans le cas où on est pas PCI-X.
 
Pour le PCI-E par contre j'ai pas étudié le truc du tout (je sais juste que c'est ni plus ni moins que 1 à 32 lignes RS485), mais le PCI étant on ne peut plus basique (très similaire à l'ISA) j'espère c'est principalement une question de conversion série/parallèle.

Non en fait pas exactement. Tout d'abord a mon sens (je ne suis pas fabricant de carte mere non plus), ce ne sont pas les chipsets mais les bios qui ne veulent pas mapper les periphs pci au dessus de 4Go. Le chipset et les bridges PCI ont les capacites de le faire d'apres ce que j'ai lu dans la spec d'un chipset Intel pour serveur recent. C juste le bios qui igoner cette possibilite.

Deuxiement chose a bien voir et qui explique que ce probleme ne soit pas non plus un enorme probleme : la memoire mappee par le pci ne couvre pas forcement toute la memoire physiquement embarquee dans la carte.

Comme je l'ecris plus haut, beaucoup font comme moi et ne mappent qu'une partie de la memoire embarquee, une banque, pour des raisons d'allegement du circuit de decodage d'adresse a l'entree de l'interface PCI (afin de pouvoir tourner a une frequence suffisante). Cette banque est selectionnee par celui qui veut acceder au periph pci par le biais d'un premier registre situe en general dans un petit espace memoire situe dans le periph comportant un tas d'autres petits registres de controle et de statut. En quelques sorte, ce petit registre de selection de banque memoire comporte le haut de l'adresse qui, recollee aux adresses qui arrivent ensuite par le PCI, formera l'adresse finale sur la memoire  embarquee (GDDR pour une carte graphique par ex). resultat, on ne mappe en general pas plus de 64Mo ou 128Mo de memoire via le PCI pour un periph et du coup, ca ne pose pas trop de probleme vis a vis de la limite des 4go, meme pour des cartes embarquant 2Go.

Apres, j'ai aussi constate que la carte graphique (une x700, une 8800GTX et meme une vieille GeForce 4 MX) n'a que sa zone de petits registres de controle de mappee par le PCI et que sa memoire GDDR embarquee ne l'est pas du tout. Cela s'explique par le fait que le processeur central n'accede pas directement a la GDDR en tant que maitre mais plutot en tant qu'esclave. Le periph PCI n'est donc jamais la cible (l'esclave) lors des acces a la memoie GDDR. C la carte graphique elle meme, par le biais de son controleur DMA, qui accede au donnees de sa memoire GDDR et les transfere en tant que maitre au processeur central.

Quand le CPU veut par ex lire des donnees se trouvant dans la GDDR de la cg, il ecrit d'abord le decriptif de la commande DMA qu'il veut effectuer (lire tant de donnees a tel endroit dans la GDDR et ramener ces donnees a tel endroit dans la RAM). Pour ca il ecrit les petits registres du controleur DMA de la cg qui se trouve dans le petit espace memoire dont je parlais qui contient les registres de controle. Le controleur DMA de la cg demarre alors et effectue le boulot. Il vient donc lire la GDDR, et une fois les donnees pretes, les envoie vers la RAM du systeme en effectuant une ecriture PCI en tant que maitre. En faisant cela, la GDDR n'a pas besoin d'etre mappee via le PCI et c ce qui semble se passer en pratique.

Donc pas trop de soucis a se faire quand meme du cote du mapping des periph PCI, les gros espaces memoire (en dehors des registres de controle donc) sont en general accedees exclusivement via DMA sinon, les perfs chutent grandement (du fait que le CPU est utilise pendant toute la procedure).

sur mon Vista 64, ma 8800GTX a 304Mo (16+256+32) de mappé (hormis l'espace A0000 pour le VGA). donc ce n'est effectivement pas les 768Mo, mais à priori un accès est forcément donné au framebuffer (logique ça a toujours existé que ce soit en VBE 2 ou en directdraw).
 
comment a-tu contrôllé l'espace mémoire mappé par les x700/8800gtx/gf4mx ?
 
 
 

Je ne te suis pas du tout la dessus. Le mieux est que tu lises des docs sur le PCI Express et le PCI avant de faire des conclusions comme ca quand meme. Le PCI-SIG est un organisme (dont mon entreprise est membre et ce qui me permet d'acceder aux parties confidentielles du site) serieux et tous les points des specs ont ete murement refelchies. C'est meme tres tres compliquees et bien loin des conclusions simplistes que tu peux essayer de donner ici.
 
Sinon, pour eviter la confusion totale, le PCIe n'a rien a voir avec des lignes RS485 (franchement ca se saurait sinon). Techniquement c'est assez complique et ca utilise des lignes differentielles pour une meilleure integrite du signal, comme c la mode sur tous les bus serie recents. La seule chose que tu dis de vrai ici est que ca passe a un moment donne par un convertisseur Serie-Parallele (un SerDes) avec un tas de traitement du signal. convertisseur 8/10b...
 
Honnettement tu melanges un peu trop les choses du reseau plus ou moins haut niveau avec des choses bas niveau d'electronique. Pense bas niveau et ca ira mieux.
Je te rappelle qu'on est dans des protocoles electriqus differents. Avant de pouvoir lire des registres, il faudrait deja que le bus soit utilisable, ce qui n'est pas le cas avant que l'initialisation se termine. Donc pour initialiser le bus, il y a d'abord une phase ou on lit des niveaux electriques qui determinent si les cartes presentes ont relie a un point de test une resistance de 10k avec un condo de 0.01uf en parallele (PCI-X 66MHz), si elles ont un court circuit (PCI) ou si elles ont un circuit ouvert (PCIX 133MHz). On est a tres bas niveau et bien loin de tes lectures de registres et autres broadcast !

Je te rappelle que l'interface PCI d'un peripherique est un circuit logique, un circuit electronique. Ce n'est pas qu'on ne peut pas "omettre" un cycle d'adresse, bien au contraire, tout est possible a bas niveau, le probleme c'est que ca cree une condition, une porte "ou" supplementaire avec derriere ce ou, un autre circuit qui sera utilise dans le cas precis ou le 2e cycle d'adresse n'est pas omis. Tout comme le circuit (on parle de chemin) utilise pour la condition "adresse 32b", le circuit utilise pour la condition "adresse 64b" doit egalement fonctionner et doit dans l'absolu etre teste. En simulation, on essaie de tester un max de combinaisons afin de couvrir l'ensemble des chemins logiques existants. On appelle ca le "code coverage" (les circuits logiques sont modelises en code Verilog ou VHDL) et ca donne le pourcentage du code (des circuits logiques) couverts par ta simulation. Les bons logiciels de simulation comme Modelsim donnent ca en general.

Sinon si y'en a que ca interesse puisqu'on est parti dans une discussion esotherique :
Les differentes bibles en matiere de PCI, mieux expliquees et a peu pres aussi complete que les specs officielles :
http://www.amazon.fr/s/ref=nb_ss_w [...] .y=0&Go=Go
Ces 3 bouquins (PCI, PCIe et PCI-X) sont pas chers en plus car chaque bouquin fait pres de 1000 pages, j'ai presque tout lu d'ailleurs !

J'ai lu les registres BAR de l'espace de config PCI de chaque carte en utilisant une commande DOS qui s'appelle dans mon entreprise redpci (ailleurs on dit peut etre readpci mais les japonais de ma boite sont nuls en anglais). Je crois que ca vient de l'exterieur donc on vous devez peut etre pouvoir la trouver, faudrait que je demande a mon softeux ou il l'a eu.

La configuration du PCI est independante de l'OS, du driver ou du directdraw puisque la taille memoire requise est cable en dur dans la carte.

Par contre je me suis peut etre trompe en donnant le nom des cartes videos que j'ai essaye. J'ai donne des noms de cartes que nous avons, sans vraiment verifier si c etait ces cartes que j'avais testees (il me semble avoir teste une carte video integree en fait mais pour le reste c pas sur).

Desole pour l'imprecision , je verifie ca tout de suite.

Mille excuses ! Il semblerait que j'ai donne des infos fausses. S'il est vrai que j'ai trouve au moins une carte, peut etre une cg integree a la cm, qui n'avait pas de BAR, il semble que ca n'est pas le cas de toutes les cartes que j'ai citees ci-dessus et que je n'avais pas du tester en fait. Je viens d'essayer avec la X700 Pro 256Mo PCIe ainsi qu'une ATI RageXL integree (classique sur les cartes serveurs meme recentes) et les deux ont des BAR pour mapper leur memoire.
Pour la Rage XL, il y a 2 BAR de 32b de memoire non prefetchable qui font 16Mo et 1Mo et un BAR d'IO de 16k.
Pour la X700pro, j'ai deux fonctions PCI. La fonction annexe ayant un BAR 64b de memoire non prefetchable de 64K. La fonction principale a un BAR 64b de memoire prefetchable qui fait 256Mo, un BAR 64b de memoire non prefetchable de 1Mo et un BAR d'IO de 4ko.
 
Je remarque deux choses, ce que je disais sur les BAR de cg etait un peu faux, et deuxiement, et ca ca ne change pas, les espaces memoire ne sont pas mappes au dessus de 4Go (puisque l'adresse ecrite dans le BAR ne comportait que des 0 au dela des 32b).
 
Desole pour l'erreur donc. Par contre ce que je veux dire, ca n'est pas que les cartes PCI ne supportent pas le 64b alors qu'elles le devraient mais plutot que les bios actuels refusent de mapper au dela de 4Go ce qui pourrait poser probleme si par exemple on avait un quad sli de 8800 768Mo dont la memoire serait entierement visible par le PCI. C'est d'ailleurs sans doute pour ca que sur ta carte Bjone, tu n'as que 256Mo de GDDR de visible par le PCI, le reste devant sans doute passer par un registre d'adresse annexe.
 
J'ai lu dans une doc que les chipsets ne pouvaient mapper les periphs pci au dela de 4go que si ceux-ci avaient leurs BAR regles en memoire prefetchable (ce qui est le cas pour ma X700 Pro mais pas pour la Rage XL). J'avais regle en prefetchable les BAR de mon periph pour lequel j'avais mis un BAR enorme de 1Go ou 2Go expres pour depasser les 4Go (comme je l'ai ecrit plus haut) et meme comme ca le bios avait refuse de mapper mes cartes au dessus de 4Go et avait du coup laisse tomber leur detection (les cartes n'etaient plus presentes aux yeux du systeme).
 
Bref, c le bios le mechant la dedans, c ca que je veux dire, desole de vous avoir embrouille avec mes histoires.

Tu confirmes que le PCI-E est similaire à du RS-485 ou RS-422, je sais pu lequel des 2 en fait (plutôt 422 si c'est sur 1 paire pour émission et réception, le RS-485 étant utilisé en 2 paires).
 
Après, le RS-422/485 n'est qu'un support physique normalisé utilisant la transmission différentielle, y'a pas de protocole propre. Il me semble d'ailleurs que l'Hypertransport est très proche du PCI-E d'un point de vue "physique".
 
En tout état de cause, l'initialisation du bus telle que je l'imaginais, c'était ni plus ni moins que la base du plug & play, à savoir une initialisation en 2 temps:
 
- contrôleur et périphs s'initialisent en mode de compatibilité
- récupération des capacités et configuration des périphs
- passage en mode complet, les périphs "sautant" les morceaux qui ne les concernent pas et le contrôleur en faisant autant
 
Ca ajoute un certain temps au démarrage mais ça reste négligeable en pratique, de même concernant le fonctionnement une fois démarré, surtout comparé à un bridage de tout le bus. On passe d'une config à la bourrin (la papatte qui dit si le périph est PCI/PCI-X) à une auto-négociation.
 
PS: le réseau ethernet est également basé sur la norme RS-485 (1 à 4 paires si ma mémoire est bonne), ils ont surtout ajouté une partie du protocole dans la norme.

les points communs entre le RS422 et le PCIe s'il y en a, sont comme tu dis au niveau de la couche physique, en particulier le fait qu'ils utilisent des paires differentielles pour faire passer le signal qui est transmis dans un seul sens (1 signal RX et un signal TX). Mais ca s'arrete la car meme au niveau physique, le RS 422 tourne a qques Mb/s alors que le PCIe tourne a 2.5Gb/s, excuse moi du peu. Je vois mal comment avec une telle difference au niveau debit, le RS422 pourrait etre la meme chose physquement que le PCIe...
Le RS485 est multipoint et donc difficilement comparable au PCIe qui est point a point. Son debit est egalement de qques Mb/s.
 
Apres j ai cru comprendre que les ingenieurs telecoms et reseaux parlent parfois de RS422 pour designer par extension des paires differentielles de signaux mais deja ca se limite a l'aspect physique (electrique) du protocole et ces inges telecoms doivent limiter ce jargon a leur monde car ca porte a confusion (et on se retrouve a faire un parallele entre RS422 et PCIe...)
 
J'avoue ne pas etre un expert en RS485 ou 422, mais la quand meme de la a me faire penser que le PCIe leur est identique... Disons que c au moins "un peu" trop simpliste comme comparaison.
 
Il existe qques petits points communs mais disons que 95% est different

Cette fois c'est vrai oui, au niveau physique seulement donc.

Ecoute Gigathlon arrete d'"imaginer" et etudies les livres sur le PCI que j'ai mentionne au dessus.
Je ne sais pas bien ce que tu veux dire par "contrôleur et périphs s'initialisent en mode de compatibilité" mais la realite est ce que j'ai explique au dessus et ce qui est ecrit dans les livres, pas ce que tu imagines...
Apres la "config a la bourrin", c la realite electrique de la chose, le bas niveau. Si le bas niveau l'electronique est qqch de bourrin, alors desole d'etre un bourrin ... (mais il en faut )
 

Ca veut dire quoi ??

Ah mais j'ai pas dit qu'il ne fallait jamais être bourrin  
 
Juste que j'imaginais la chose un peu moins "bas niveau" que ça justement, après avoir vu pas mal de composants qui suivaient ce principe...
 
Maintenant, il est vrai que le PCI c'est pas tout jeune, ceci peut expliquer celà.
 
Pour la phrase que tu cites, simplement utiliser des communications PCI-X pour tout le monde, quitte à brider le périphérique PCI en omettant la moitié des données présentes sur le bus. Raisonnement derrière la chose: plutôt que de brider les périphs qui ont besoin de BP (sinon ils ne seraient pas en PCI-X, logique implacable), on bride les périphs PCI (ou pas... après c'est pu du tout clair pour moi).
 
Après, c'est peut-être toi qui m'a induit en erreur, dans le cas où le contrôleur pourrait passer du mode PCI au mode PCI-X et de 33 à 133MHz à volonté, le PCI ne bridant alors pas tout le monde mais travaillant comme il sait le faire avant que le contrôleur ne rétablisse un bus PCI-X. (en tout état de cause, il me semble que depuis un moment on trouve 2 contrôleurs distincts sur les mobos PCI-X, autre solution au problème, de bas niveau encore )

D'accord, je viens de comprendre ce dont tu parlais.
Mais le PCI-X etant plus jeune que le PCI, les periph PCI ne supportent pas le PCI-X et donc on bride les periphs en PCI-X (qui eux supportent le PCI) pour que tout le monde fonctionne.

Sinon, si je comprends bien ce que tu veux dire, tu voudrais faire fonctionner le bus PCI-X sous les deux protocoles a la fois dans le cas ou il y a des cartes PCI et des cartes PCI-X raccordees au meme bus. Ca n'est malheureusement pas possible car contrairement au PCI, le bus PCI-X est un bus "registered" c a dire que les signaux traversent une porte logique de type Flip Flop ce qui leur confere une plus grande latence (+1 clk) mais une meilleure stabilite. Le bus lorsqu'il fonctionne en PCI-X s'adapte vis a vis de cette latence.
Au niveau electrique, les delais de transmissions des signaux, le setup et le hold entre autres, sont donc differents en PCI-X et en PCI et on aurait des erreurs sur les signaux si jamais on avait a faire fonctionner deux protocoles en meme temps (sans parler du casse tete au niveau du circuit logique derriere qui doit savoir quel transaction est en quel protocole ...).

Enfin, le fait de passer par des flips flops en PCI-X permet a celui ci de fonctionner a 66MHz ou 133Mhz ce qui n'est pas possible avec le PCI physiquement moins stable qui se limite souvent a 33MHz, surtout si il y a plus d'une carte de connectees sur un meme bus. Or l'horloge du bus, que tu le veuilles ou non, y'en aura toujours qu'une seule et il faudrait alors faire marcher les periphs PCI-X a 33Mhz ce qui n'a pas grand interet...

Pour terminer, disons que la situation n'est pas si grave. Deja les periphs PCI-X ne sont pas tres nombreux. Deuxiemement, la plupart des cartes meres ont un bus independant pour certains slots. Typiquement sur les cartes les mieux fournies, on peut avoir par ex 6 slots PCI-X. 3 slots sont parfois sur le meme bus, et les 3 autres slots sur 3 bus differents. En mettant les cartes bridant le systeme sur des bus independants, on permet aux autres de fonctionner dans leur protocole optimal. Si jamais l'utilisateur melangeait sur un meme bus une carte PCI avec une PCI-X, le driver de l'une des cartes est charge de prevenir l'utilisateur sur le fait qu'il ferait mieux de changer l'emplacement de la carte pour ne pas diminuer les performances (en realite je ne sais pas si c'est fait cela dit).

 
non non, c'est très interressant, j'avais jamais été voir quelle quantitée de mémoire adressable était mappée par nos cartes modernes et réfléchi à la problèmatique.
 
en fait c'est vrai que c'est potentiellement censé: un framebuffer de 2048x1536 en 32bpp fait 12Mo, donc avec 256Mo de mappé ça peut faire au moins 4 framebuffers (donc écrans) dans cette résolution triple-bufferés (144Mo), donc largement de quoi faire des applis qui veulent faire du rendu en direct dans un framebuffer.
 
pour les textures ou autres ressources, soit elle sont DMA-ifiées ou accédées en DME via le gart pour les cartes AGP, soit uniquement DMA-ifiée en globalité ou par page (si virtualisation) en PCIe. d'ailleurs pour la virtualisation, on a toujours du mal à savoir ce que sont capables les geforce 8 et les radeon 2xxx à ce niveau (si c'est implémenté comme un CPU avec un système de page-fault où le GPU notifie au driver un page-fault avec donc la page a DMA-ifier et la table des pages GPU a actualiser en conséquence, enfin si c'est fait comme sur un CPU).
 
par contre, là où je me pose la question, c'est au niveau du verouillage d'une ressource GPU et de l'écriture en mémoire vidéo direct.
alors effectivement quand tu lockes la ressource via le Direct3D ou l'OpenGl, il est probable que le driver fasse que le GPU mappe la portion de la mémoire vidéo concernée dans les 256Mo d'exposés au CPU.

 
en même temps le PCI-X va mourrir au profit du PCIe non ? (coté grand public c'est réglé, coté pro si ça se fait plus tard, c'est toujours à cause du parc et du suivi produit plus que des raisons techniques)

Ouh la, il faudrait que je demande a mon softeux de service (c lui qui fait les drivers et il connait surement un peu comment ca marche au niveau des cg) !
En ce qui concerne la virtualisation en PCIe, est-ce que tu parles des "virtual channels" ? ils definissent des niveaux de priorite plus ou moins eleve selon que la latence est importante pour une appli temps reel (diffusion d'une video en H.264 par ex) ou non. Perso, je vois tout le monde implementer seulement le canal 0 (le canal par defaut c a d celui qui n'a pas de priorite particuliere) mais je ne sais pas pour les cartes graphiques (c un peu pour elles qu'a ete cree ce systeme de canaux virtuels d'ailleurs puisqu'elles ont besoin de temps reel pour les lectures de videos entre autres).

Sinon, je sais pas si c ce que tu as voulu dire mais le mapping de la memoire dans les BAR du PCI (ou X ou Express) ne depend pas d'un mode de fonctionnement (Direct3D ou OpenGL ou ce que tu veux) mais est fait au demarrage du PC selon la taille memoire demandee qui est cablee en hard dans l'interface PCIe de la carte graphique. Si 256Mo de GDDR sont visibles par le CPU (ou plutot par le bridge PCI), ils le resteront toujours qque soit le mode de fonctionnement.

C clair, tout a fait d'accord. C le chef de la R&D qui est a la masse dans ma boite. Je lui ai fait une belle interface PCIe pourtant mais il a prefere que je termine l'interface PCI-X pour aller sur le produit de l'an dernier qu'on avait et a range ma belle interface PCIe (presque finie pourtant) au placard, l'ingrat ! Et le pire c que maintenant notre carte a ses perfs limitees par l'interface PCI-X !
Dans le genre frustrant, il a fait fort

 
en fait ce dont je parles, c'est indépendant de la couche physique/liaison, donc encore plus hors-sujet par rapport à notre discution . (mais c'est histoire de discuter)
 
en fait l'idée, et ça un peu commencé avec l'AGP et le mode DME (avec le GART coté chipset), c'est d'exposer au GPU plus de ressources qu'il n'en a.
 
quand tu fais un rendu en D3D ou en OpenGl, bin bah tu assignes des textures à de la géométrie et tu fais traçer.
 
le problème c'est que si les ressources sont trop importantes pour la carte 3D, soit ça va pas passer du tout (in your face no, de la part de l'api) soit ça va ramer parceque les ressources se poussent les unes les autres (et tu passes tout ton temps à DMA-ifier de la ressources pendant que le GPU glande).
 
l'évolution vers laquelle on tend (et qui est en principe présente sur les gf8/rad2xxx, et peut-être pas exposé par le modèle de driver d'Xp, et donc là Vista risque d'avoir un avantage mais peut-être qu'en D3D10 à voir je sais pas), c'est de virtualiser l'espace mémoire vu du GPU, de manière à ce que une machine avec 8Go de ram système, ayes ses 8Go de projetables dans l'espace GPU de manière transparente (avec un working set praticable équivalent à la ram vidéo embarquée sur la carte vidéo) .
 
en gros classiquement, si tu as un texture de 256Mo que le GPU va devoir utiliser, il faut DMA-ifier toute la texture (la texture est une ressource atomique, blocage du GPU en attendant le transfert, giclage d'autres textures pour faire de la place qui devront être re-transférées à l'utilisation suivante).
 
si le GPU supporte une virtualisation mémoire à la manière MMU des CPU, il va découper un large espace mémoire très large (plusieurs Go, enfin ça après c'est empirique suivant le meilleur compromis du moment), en petites pages (bon un cpu en mode classique c'est 4Ko, un GPU ça peut être largement plus gros, donc on va dire 4~1024Ko), et ces pages de ressource vont être DMA-ifiées à la demande (par notification auprès du driver) au fur et à mesure que les GPU touche les pages (qui n'ont pas étés copiées).
 
ça a deux avantages:
- temps de blocage potentiellement plus court (pas de grosse copie violente avant exécution, donc moins de temps perdu d'un coup)
- même comportement qu'avec un CPU: notion de working set, même si la scène utilise une texture de 512Mo, il se peut que seul 4Mo soit réellement touché par le GPU.  
et donc à même quantitée de mémoire vidéo, la carte 3D peut rendre des scènes sensiblement plus lourdes (après si le "working set" est supérieur à la mémoire vidéo, les performances s'écroulent, comme le working set d'une application qui dépasse la ram système et oblige windows à swapper ou à un cache bin a plus cacher )
 
après tu as des contre-coups: quelques (millions) de transistors consommé coté GPU pour le mmu et le cache de la table des pages, plus d'activité CPU coté driver tant que la situation de pagination ne s'est pas stabilisé coté GPU.
 
bon là, on est au-dessus de l'aspect adressabilité des périphériques. (même si... mm....)

je comprends en gros ce que tu dis quoiqu'une bonne partie depasse largement mon domaine de connaissances...
Deja petite precision de vocabulaire pour etre sur. Quand tu dis DMA-ifier ca veut dire demander un transfert DMA ?
Deuxieme remarque au passage aussi: d7apres ce que je comprends de ce que tu dis, les transferts DMA de grosses quantites de donnees entre la memoire centrale et le GPU risque de faire attendre le GPU et c la technique de virtualisation de memoire que tu expliques qui y palie. Cela dit, si vraiment le GPU est souvent en train d'attendre que les transferts DMA se termine, c cense etre a cause de la lenteur du bus de donnees, donc recemment du bus PCIe x16. Or on dit que celui-ci est pour le moment largement suffisant pour ne pas limiter les perfs des cartes graphiques. Si il limitait, on devrait sentir que les perfs diminuent nettement en passant de 16x a 8x et ca n'est pas le cas.
 
Est-ce que tu penses que si on ne voit pas de limitation due au PCIe, c justement parce qu'il y a des techniques comme celle dont tu parles qui permettent de masquer la lenteur du bus PCIe x16 ou bien est-ce que tu penses que le PCIe x16 est de ttes facons suffisant dans l'absolu pour les cartes graphiques actuelles ?

Y'a un peu des 2 je pense, le fait qu'on travaille beaucoup sur des données pré-chargées ou "pré-calculées" (pas tout à fait en fait, mais on calcule des données temporaires avant de s'en reservir, par exemple dans le cas des ombres portées) doit jouer pas mal.
 
Du coup on envoie plus de la géométrie (vecteurs) qu'autre chose, et ça prend pas énormément de temps.
 
Dans tous les cas, tous les GPU sont plus ou moins capables de virtualiser leur espace RAM quel que soit l'OS, sinon je vois mal comment ils nous auraient pondu le Turbocrash et l'Hypememory (oui, c'est fait exprès )

(oui pour la demande du transfert DMA)
 
en fait la virtualisation, va permettre deux choses:
 
- manipuler des scènes théoriquement trop grosses pour les ressources de la carte vidéo (c'est le premier point c'est ce qui permet aux cartes Hypermemory & Turbo-cache de prétendre avoir 4x plus de mémoires qu'elle n'en ont physiquement)
 
- avoir un transfert des ressources plus "coulé" dans certaines situations (pas dans toutes ).
 
pour la suffisance du PCIe 16x ou 8x, c'est dû au fait que les ressources tiennent en ram vidéo, et après les premières frames le PCIe ne transfert plus que les ordres de traçage.
 
donc la tolérance vis à vis de la vitesse du bus, est plus lié à la fréquence de transfert de ressources.
 
dans un jeu basique ça passe bien, dans d'autres types de traitement ça passera moins bien. (ie tout ce qui va demander un aller-retour sur le PCIe pour être ré-exploité par le CPU)
 
donc si le PCIe x16 est suffisant c'est lié aux pratiques, c'est lié au fait que les scènes rentrent dans la ram vidéo

 
a zut j'ai skippé ton post oui effectivement. mais à priori par exemple les 6800 et 7900 ne semble pas avoir héritée de la R&D sur la 6200 turbocache.
 
en fait sur la 6200 c'est correct, parceque la bande-passante du PCIe est assez proche de la bande-passante de la ram vidéo embarqué.
 
peut être que le haut de gamme l'écart était tel que ça n'en valait pas le coup. maintenant peut-être que la pagination était trop basique pour espérer avoir un comportement plus CPU-like.

d'accord Gigathlon et Bjone

donc si je comprends bien, le temps de transfert PCIe des donnees suivantes est masque par le traitement par le GPU du paquet de donnees courant. Celui-ci est entierement contenu en RAM video ce qui evite de couper le traitement effectue par le GPU pour transferer la suite.

Sinon pour la virtualisation, je n'avais meme pas fait le rapprochement avec le turbocrash et l'hypememory (ca sonne pas mal comme ca remarque )

Merci pour les precisions

d'un point de vue temporel, le problème c'est que si c'est une texture, en même temps le GPU ira plus vite à consommer la page que le PCIe a amener les nouvelles (donc il va bloquer).
 
c'est plus une optimisation "spacialo-temporelle", ie si tu prends une texture 4096x4096 en 32bpp de 64Mo pour le mipmap 0, donc 86Mo pour toute la chaine de mipmaps, t'en mets 2 (diffuse+gloss+normal-map....) sur une voiture, donc 172Mo.
 
si ta voiture est initialement au loin, le LOD va sélectionner un mipmap assez élevé, donc un mipmap de faible résolution: la version décimée de la texture qui fait 4x4 pixels soit 64 octets (32bpp), donc le système de virtualisation va toucher une page autour du mipmap des deux textures, donc tu vas avoir deux pages de 64Ko (si on part avec une page de 64Ko, les 4Ko CPU classiques me semble trop peu), donc mettons 128Ko qui vont être transferées sur le PCIe et mis en ram vidéo.
 
tant que la voiture reste au loin aucun transfert ne se fait, et la conso vidéo est de 128Ko (au lieu de 172Mo).
là où une carte conventionnelle, se tape le transfert et le stockage des 172Mo.
 
au fur et à mesure que la voiture se rapproche, des nouvelles pages de textures vont être touchées jusqu'a avoir transferré les 172Mo.
 
mais progressivemment d'image en image au fur et à mesure de l'évolution de la voiture dans le champ de vision.
 
le cas défavorable (où la technique ne sert à rien voir rajoute de l'overhead), c'est si dès la première frame la voiture est très proche et le gpu sélection le mipmap pleine résolution, et là le transfert et la conso seront plus proche des 172Mo initiaux.

ok, bon je comprends pas tout mais d'accord quand meme

bon on a dévié de manière itérative
 
bin en fait c'est simple: si tu prends une voiture au loin, qui se rapproche de toi, plus elle est proche, plus elle implique de la consommation de mémoire vidéo.
 
l'idée de la virtualisation (dans ce cadre là), c'est que cette consommation se fait progressivement quand elle est vraiment nécessaire, alors qu'autrement tu as dans toute les situations la pleine consommation.

je vois

hummm et comment utiliser reellement les 4 go de ram sous vista 32 bit au lieu de n'avoir que 3.25 go ?

Passer à Vista64

 
Et subit ce qu'il en est