Transfert de données sur le bus PCI en mode réèl

Transfert de données sur le bus PCI en mode réèl - ASM - Programmation

Marsh Posté le 02-09-2004 à 10:58:53    

Bonjours tout le monde.
 
Un petit problème me dérange. Je mets 4ms pour tranférer 8ko de données d'un bus PCI (ca fait 2Mo/s, alors que le bus PCI est sensé permettre des transferts jusqu'à 132Mo/s).
 
But de la manip : transférer les données d'une carte PCI à base de chip PLX9052 (mappée en E8000000 et des poussières sur ma machine) vers la mémoire conventionnelle histoire qu'un bon vieux programme en turbo pascal 7 sous DOS puisse travailler dessus.
 
Principe : J'ai écrit une routine en assembleur qui me permet (à coup de passage en mode protégé, de ptites modifs sur les registres de segment, puis de retour en mode réèl) d'aller choper les données.
 
Ma boucle de copie des données ressemble à ca (de mémoire, j'ai pas le code sous les yeux - pas de net au taff) :

Code :
  1. ;chargement dans ds et es des segments qui vont bien.
  2.   mov   edi,2000h ; 8ko
  3.   mov   esi,2000h ; 8ko
  4.   mov   cx,800h   ; nombre d'itérations pour faire 8ko par copie de dword
  5.   ;je sais pu quelle instruction ici pour placer le drapeau correctement pour spécifier le sens descendant de la boucle loop.
  6. laboucle:
  7.   movsd
  8.   loop  laboucle


 
Avec ca, je récupère correctement mes données, mais je trouve que 4ms pour executer ca, c'est très très lent.
 
J'ai esssayé de laisser le proc en mode réèl le temps de faire mon transfert, j'ai essayé de désactiver les ITs pendant mon transfert, mais cela ne change rien (4ms pour la boucle).
 
Pour info, le PC est un NEC à base de carte mère Intel et de Celeron 2GHz...
 
Question du jour : Est ce qu'il y a quelque chose de spécial à faire pour demander un transfert de données rapide sur le bus PCI ?

Reply

Marsh Posté le 02-09-2004 à 10:58:53   

Reply

Marsh Posté le 02-09-2004 à 13:28:10    

Mackila a écrit :

Bonjours tout le monde.
 

Code :
  1. ;chargement dans ds et es des segments qui vont bien.
  2.   mov   edi,2000h ; 8ko
  3.   mov   esi,2000h ; 8ko
  4.   mov   cx,800h   ; nombre d'itérations pour faire 8ko par copie de dword
  5.   ;je sais pu quelle instruction ici pour placer le drapeau correctement pour spécifier le sens descendant de la boucle loop.
  6. laboucle:
  7.   movsd
  8.   loop  laboucle


 
Pour info, le PC est un NEC à base de carte mère Intel et de Celeron 2GHz...
 
Question du jour : Est ce qu'il y a quelque chose de spécial à faire pour demander un transfert de données rapide sur le bus PCI ?


 
Attention, je vais peut-être dire de grosses conneries. Mes excuses d'avance.
 
Déjà, ta boucle risque d'aller beaucoup plus vite avec

Code :
  1. rep movsd

plutôt qu'avec ton vilain loop.
 
Ou mieux encore, en faisant la copie à la main, et en déroulant le code (je ne suis pas sûr pour ça: c'était le cas avec les vieux processeurs de type Pentium):

Code :
  1. mov eax, ds:[esi]
  2. mov ebx, ds:[esi+4]
  3. mov es:[edi], eax
  4. mov es:[edi+4], ebx

 
 
Pour plus d'infos:
Procs intel: http://www.intel.com/cd/ids/develo [...] htm?page=6
 
Procs AMD: http://cdrom.amd.com/devconn/event [...] _paper.pdf
 
 
D'autre part, il me semble que pour obtenir de grosses perfs, il faut que ta carte PCI utilise le DMA plutôt que de passer par le processeur...
 
J'espère ne pas avoir dit trop de conneries.  :??:


Message édité par Lam's le 02-09-2004 à 13:41:46
Reply

Marsh Posté le 02-09-2004 à 13:40:09    

"rep movsd" est encore le plus rapide sur x86 en dehors des registres mmx/sse. Ca changera peut-être bientôt.
Il ne fauf maintenant plus utiliser movs<x> qu'avec rep. Et "loop" est très lent, il vaut mieux faire un :
dec ecx
jnz laboucle

Reply

Marsh Posté le 03-09-2004 à 21:27:10    

lit mon topic sur le transfert mémoire.

Reply

Marsh Posté le 03-09-2004 à 23:22:42    

sur le bus PCI, le rendement du CPU n'est pas critique.
 
par contre tu écris par adresse croissante ou adresse décroissante ?
 
le PCI étant multiplexé et orientée rafale, si ton approche impose de balancer une nouvelle adresse pour chaque transfert, le débit est cassé.
 
donc attention au PCI: tu as plein de subtilitées locales au PCI qui feront que le débit effectif sera facilement à chier.

Reply

Marsh Posté le 03-09-2004 à 23:33:32    

Perso j'avais avant d'écrire mon movsd/loop, utilisé un truc genre :

Code :
  1. ; gs et fs chargés en ayant comme base les @ source et destination de la copie...
  2.   mov   eax,dword ptr gs:[ebx]
  3.   mov   dword ptr fs:[ebx],eax


, le tout étant un poil déroulé. Et j'avais exactement les mêmes performances (puis pour une boucle exécutée 512 fois, c'est un peu craignos 4 ms sur un celeron 2GHz).
 
Donc j'en ai déduit que c'était le transfert sur le bus PCI qui fait ramer... J'en suis donc à me demander comment faire un transfert rapide sur le bus PCI.
 
/me scroll la page vers le bas et voit la réponse toute fraiche de bjone
 
Très intéressantes toutes tes remarques :) !
Ma boucle est descendante dans les adresses...
 
Bjone> Aurais-tu des docs ou des infos supplémentaires sur les "subtilitées locales au PCI qui feront que le débit effectif sera facilement à chier" ? (dans quel ordre faire des lectures ou des écritures, etc, etc,... )
J'essaierais Lundi de faire ma boucle croissante dans les adresses.

Reply

Marsh Posté le 04-09-2004 à 00:29:01    

Utilise la FPU tu y gagnes à mort...
 
Dans le même genre, evite les descripteurs étendue : fs/gs
ds/es est préférable.


Message édité par christophe_d13 le 04-09-2004 à 00:29:52
Reply

Marsh Posté le 04-09-2004 à 00:34:22    

Mackila a écrit :


Ma boucle est descendante dans les adresses...


 
d'une maniere generale, c'est une mauvaise chose

Reply

Marsh Posté le 04-09-2004 à 01:57:54    

je pense que la boucle décroissante empêche d'émettre par par rafales.
 
je me souviens plus de mes benchmarks à l'époque des mes jeux en vga/vesa, mais y'a beaucoup de chances que si tu émets en décroissant, tu te retrouves peut-être avec une adresse pour un DWORD émis (et tout un paquet de signaux de contrôles), ou lieu d'une adresse et tout une rafale.

Reply

Marsh Posté le 04-09-2004 à 02:10:04    

tiens regarde ça:
http://www.techonline.com/communit [...] icle/20025
(trouvé vite fait)

Reply

Marsh Posté le 04-09-2004 à 02:10:04   

Reply

Marsh Posté le 04-09-2004 à 09:36:21    

Sur mon site :

Mesures 1998
Un Pentium 166 standard fonctionnant à 3x75 soit 225 MHz. La carte mêre est une ASUS T2P4 équipée de 512Ko de cache avec 32 Mo de mémoire EDO à 60ns. La carte vidéo est une Tseng ET6000.
En mode de copie mémoire RAM : La vitesse atteint 95 Mo/s soit une bande passante totale de 190 Mo/s.
Si la copie est faites vers la carte vidéo en mode VGA 320x200x256 ou VESA 640x480x256, la vitesse de transfert atteint 70 Mo/s soit une bande totale de 140 Mo/s en cumulant le PCI et la RAM.
Enfin, si la copie se fait en ModeX, la vitesse atteint 38 Mo/s soit au total 76 Mo/s.
 
La cartes mêre fonctionnant avec un bus à 75 MHz, permet une plus grande vitesse. Bien sur à 83 MHz, c'est encore mieux…
Le bus PCI fonctionne ici à 75/2 soit 37,5 MHz. Soit une bande passante théorique maximale de 75 Mo/s puisque il y a un cycle d'attente.


 
http://kristahl.design.free.fr/Art [...] nsfert.htm

Reply

Marsh Posté le 06-09-2004 à 16:36:42    

Résultats :
Passer la boucle dans l'ordre croissant des adresses ne change rien. :/

Reply

Marsh Posté le 06-09-2004 à 16:41:58    

Je n'ai qu'un mot, block-prefetching !
Egalement interressant pour faire de la copie RAM locale vers PCI/AGP...
Tu peux ainsi saturer le bus PCI/AGP.
http://forum.hardware.fr/hardwaref [...] 4716-1.htm
http://forum.hardware.fr/hardwaref [...] tm#t794189
http://forum.hardware.fr/hardwaref [...] tm#t798544

Reply

Marsh Posté le 06-09-2004 à 20:30:13    

Sympa ton thread (et très interessant ;) ), Christophe_d13, mais je ne pense pas dans mon cas que la vitesse du processeur soit déterminante pour la copie. Je ne parle dans mon cas que de 8 malheureux ko...
Je ne voie pas comment résoudre ce problème, qui est d'ailleur plus un léger désagrément qu'un réèl problème (si l'automate cycle en 54ms au lieu de 50ms, ce n'est pas la mort...). Ce qui me pose un problème dans cette histoire, c'est de ne pas comprendre pourquoi c'est lent... :(
 
récapitulatif :
J'ai essayé dans le sens adresses croissantes / adresses décroissantes, avec une copie à coup de mov reg,mem / mov mem,reg et une à base de movsd. Dans tous les cas ca prends autours de 4ms.

Reply

Marsh Posté le 07-09-2004 à 05:47:16    

Essaye donc une copie à l'aide de la fpu comme dans mes exemples.
L'intérêt de la copie FPU (ou MXX/SSE) est d'exploiter pleinement le bus en 64 bits alors qu'avec movsd ou mov, le transfert se fait en 32 bits.

Reply

Marsh Posté le 07-09-2004 à 21:51:00    

Mes transferts se sont sur un bus PCI 32bits, et je dois rester compatible 486...

Reply

Marsh Posté le 08-09-2004 à 01:31:45    

DX ou SX ?

Reply

Marsh Posté le 08-09-2004 à 09:29:05    

DX=FPU
SX=sans fpu
 
mais rien ne t'empèche de faire du block prefetching.

Reply

Marsh Posté le 09-09-2004 à 11:58:01    

Bonjour à tous,
 
Ayant déjà fait la même expérience que Mackila, je peux dire que la limite vient du mode de fonctionnement du bus PCI lui-même, ce n'est pas la peine d'essayer à tout prix d'optimiser une simple boucle de copie. Malheureusement, la seule alternative est effectivement le DMA si tu veux pouvoir aller plus vite. Le problème vient du fait que sur un PC, le PCI ne fonctionne en mode BURST que lors d'un transfert DMA, merci Intel (le mode BURST peut-être activé sur une plateforme de type XSCALE ou PPC). Il faut que tu vérifie si le PLX9052 supporte le transfert DMA, ce n'est pas le cas de tous les PLX. Bon courage !

Reply

Marsh Posté le 09-09-2004 à 15:22:32    

Jayl> Tu as oublié un paramêtre important.
Il y a un tampon d'écriture...
Ce n'est donc pas la boucle qu'il faut optimiser mais plutôt maximiser la lecture des données de la RAM et maximiser l'écriture en PCI (ou vice-versa).
Avec une rep movsd, on est loin de saturer le bus PCI (132MB max en pointe).
Si la carte PCI dispose également du tampon d'écriture, on peut aller encore plus vite et saturer le bus (dans la limite de l'utilisation en transfert standard).
 
Up> Il peut également être interressant de créer une tâche en parallème s'occupant de faire un transfert des données par petit bloc. A tester (mais j'ai jamais essayé).


Message édité par christophe_d13 le 09-09-2004 à 15:24:08
Reply

Marsh Posté le 09-09-2004 à 16:11:24    

christophe_d13> Je n'ai rien oublié, je travaille depuis 2 ans sur une carte d'acquisition PCI et après avoir passé plus de six mois à transférer des données sans DMA et a potasser la doc PCI, on n'a pas eu d'autre choix que d'utiliser le DMA pour faire les transferts rapidement.

Reply

Marsh Posté le 09-09-2004 à 17:25:10    

Jayl> Carte d'acquisition... J'avais oublié le principal. Désolé. :jap:  
 
Ce que j'ai dit n'est valable que dans le sens :
RAM=>PCI
 
Dans le sens PCI=>RAM c'est l'hécatombe... Mais je n'ai jamais trop cherché dans cette voie.
 
Une idée au passage : S'il faut transférer des blocs, est-ce qu'en transferant des blocs plus petits ou "entrelacés" pour faire un pré-traîtement, est-il possible de reporter le processing dans le temps ?
Un exemple concrêt (je ne connait pas le but de l'acquisition dans le cas qui nous interresse, mais prenons de la vidéo) :
Une image de 720x576 points est acquise par la carte.
On doit déterminer si l'image nous interresse, pour cela, il faut chercher des éléments de référence.
Alors on décide de transférer une ligne sur 4, soit 720x144 points. On réajuste la référence, et si la comparaison est juste, on transfere des lignes supplémentaires, et ainsi de suite...
 
Up> Si le bas-niveau est à fond, il faut repenser le haut-niveau, donc l'analyse en prenant en considération les contraintes physiques.


Message édité par christophe_d13 le 09-09-2004 à 17:33:35
Reply

Marsh Posté le 10-09-2004 à 03:02:40    

christophe_d13 >> t'est vraiment sûr qu'un rep movsd peut pas saturer un PCI ? très franchement avec la bande-passante FSB, je vois pas trop comment ça ne pourrait pas être le cas.

Reply

Marsh Posté le 10-09-2004 à 07:57:52    

Le bus communique en 64 bits au sein du cpu. En externe sur le PCI, on est en 32 bits. Mais en mode rep movsd, la bande passante n'est pas maximisée (voir mon topic sur la copie mémoire).

Reply

Marsh Posté le 10-09-2004 à 14:36:26    

christophe_d13 a écrit :

[...]
Ce que j'ai dit n'est valable que dans le sens :
RAM=>PCI
 
Dans le sens PCI=>RAM c'est l'hécatombe... Mais je n'ai jamais trop cherché dans cette voie.
 
[...]
 
Up> Si le bas-niveau est à fond, il faut repenser le haut-niveau, donc l'analyse en prenant en considération les contraintes physiques.


 
Je suis d'accord, la. Au lieu de tout transférer, je pourrais ne récupérer que ce dont j'ai besoin. Mais pour cela il me faudrait le temps de redévelopper toute mon unité, et je fini mon stage dans à peine une semaine. L'unité fonctionne, même si je perds 4ms par cycle. Je laisse tous les renseignements nécessaires pour que quelqu'un puisse faire la modification plus tard...
 
Quand au PLX9052, a première vue il ne supporte pas les transferts en DMA. Donc pour faire une grosse _et_rapide_ copie de bourrin, c'est loupé...
 
En tout cas merci à tous pour vos conseils ;)

Reply

Marsh Posté le 10-09-2004 à 15:08:31    

christophe_d13 a écrit :

Le bus communique en 64 bits au sein du cpu. En externe sur le PCI, on est en 32 bits. Mais en mode rep movsd, la bande passante n'est pas maximisée (voir mon topic sur la copie mémoire).


 
oué mais il y a tous les tamponnages, et utilisation de la cache.
 
dans le sens RAM->CPU, c'est une ligne de cache, utilisaation max du FSB.
 
par contre poteniellement, lors des écritures CPU->PCI le FSB n'est pas forcément utilisé à fond. (je ne sais pas si le CPU cumule les écritures dans un tampon pour émettre en rafale sur le FSB).
 
pour le cas de l'espace mémoire des cartes vidéos, le bios active l'USWC au niveau CPU, et si tu fais des écritures 8 bits, c'est cumulé dans une ligne de cache pour envoyé le tout le plus rapidement possible, mais sans l'USWC je sais po quelle stratégie est utilisée.

Reply

Marsh Posté le 10-09-2004 à 15:20:00    

ha oui merde je raisonne aussi dans le sens RAM=>PCI. :D

Reply

Marsh Posté le 11-09-2004 à 12:43:43    

Le problème avec tout ça, c'est qu'il y a tellement de tampons intermédiaire, qu'il devient difficile de vraiment savoir ce que l'on fait.
Le seul moyen restant, c'est la mesure selon plusieurs stratégies.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed