Affichage dynamique performant
cs_mounjetado
Messages postés
66
Date d'inscription
lundi 13 mars 2006
Statut
Membre
Dernière intervention
4 août 2008
-
28 août 2006 à 17:55
cs_mounjetado Messages postés 66 Date d'inscription lundi 13 mars 2006 Statut Membre Dernière intervention 4 août 2008 - 1 sept. 2006 à 10:08
cs_mounjetado Messages postés 66 Date d'inscription lundi 13 mars 2006 Statut Membre Dernière intervention 4 août 2008 - 1 sept. 2006 à 10:08
19 réponses
cptpingu
Messages postés
3837
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
28 mars 2023
123
28 août 2006 à 19:20
28 août 2006 à 19:20
Est-ce que ton application utilise des threads ?
Si ce n'est pas le cas, tu peux essayer de les utiliser et de placer la priorité du thread en mode "haute priorité".
Si ce n'est pas le cas, tu peux essayer de les utiliser et de placer la priorité du thread en mode "haute priorité".
elguevel
Messages postés
718
Date d'inscription
jeudi 19 décembre 2002
Statut
Membre
Dernière intervention
22 novembre 2016
3
28 août 2006 à 22:05
28 août 2006 à 22:05
Oui, lLes thread, c'est ce qui à de mieux pour ce genre d'appli :-)
<!-- blocPrincipal -->
/\_/\
( o.o ) ~ ElGuevel ~
> ^ <
<!-- blocPrincipal -->
/\_/\
( o.o ) ~ ElGuevel ~
> ^ <
cs_Forman
Messages postés
600
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
6 avril 2010
1
29 août 2006 à 01:27
29 août 2006 à 01:27
Ca dépend si tu souhaites faire une simple courbe, tu peux utiliser opengl (ça ne devrait pas être trop compliqué si tu ne souhaites pas faire d'effets trop compliqués). De cette façon là, il est possible d'afficher la courbe au moins 60 fois par secondes, et tu n'es pas obligé d'utiliser un thread secondaire d'affichage (si toutefois une fréquence de mesure de 60Hz est suffisante pour ton appli).
Tu peux utiliser mon composant TGlWinControl (le package à installer est téléchargeable ici), en mettre un sur ta fiche et lorsque tu souhaites afficher le graphique tu peux faire quelque chose de semblable à ça:
procedure TForm1.Draw;
var
a:Integer;
T:array[0..100] of Double;
begin
for a:=0 to 100 do
T[a]:=Random; // on remplit le tableau avec des valeurs (comprises entre 0 et 1)
GlWinControl1.Canvas.Lock; // on commence le tracé
try
glClearColor(0,0,0,0); // Couleur d'effacement de la surface: du noir (RGB=0,0,0)
glClear(GL_COLOR_BUFFER_BIT); // On efface la surface
glMatrixMode(GL_PROJECTION); // Matrice de projection:
glLoadIdentity; // on la "reset"
gluOrtho2D(0,1,0,1); // projection dans le carré (0,0),(1,1)
glColor3f(1,1,1); // Couleur de tracé: du blanc (RGB=1,1,1)
glBegin(GL_LINE_STRIP); // On commence à faire une suite de lignes
for a:=0 to 100 do
glVertex2f(a/100,T[a]); // On définit la position des sommets de la suite de lignes
glEnd; // Fin de la suite de lignes
finally // Dans tous les cas (même s'il y a eu une erreur):
GlWinControl1.Canvas.UnLock; // fin du tracé (nécessaire pour éviter des problèmes)
end;
end;
Bon moi je remplis le tableau T avec des valeurs aléatoires comprises entre 0 et 1, il faudra que tu mettes à la place de T[a] les valeurs que tu souhaites représenter (éventuellement en les modifiant pour qu'elles soient comprises entre 0 et 1). Une telle procédure s'effectue sans problème à 60 Hz par exemple si la fréquence de rafraichissement de ton écran est de 60 Hz... (mais si ton driver n'a pas activé sa fonction de synchronisation verticale, ce code peut s'exécuter plusieurs centaines de fois par secondes sur une carte graphique standard!).
Si tu veux avoir une idée de la vitesse chez toi, mets un Timer avec Interval=10 dans un nouveau projet, et dans son événement OnExecute mets la procédure précédante. Tu verras que ça va très vite! (en tout cas beaucoup plus vite qu'avec les fonctions de base de TCanvas par exemple). Mais c'est vrai que si tu veux quelque chose qui va encore plus vite (ou plutôt qui ne ralentisse absolument pas le thread de mesure), il faudra faire l'affichage dans un 2ème thread, et protéger tes données avec une section critique par exemple. Mais même si tu utilises une solution multi-thread, OpenGl peut être une bonne solution pour faire des graphiques efficaces et qui vont vite.
Tu peux utiliser mon composant TGlWinControl (le package à installer est téléchargeable ici), en mettre un sur ta fiche et lorsque tu souhaites afficher le graphique tu peux faire quelque chose de semblable à ça:
procedure TForm1.Draw;
var
a:Integer;
T:array[0..100] of Double;
begin
for a:=0 to 100 do
T[a]:=Random; // on remplit le tableau avec des valeurs (comprises entre 0 et 1)
GlWinControl1.Canvas.Lock; // on commence le tracé
try
glClearColor(0,0,0,0); // Couleur d'effacement de la surface: du noir (RGB=0,0,0)
glClear(GL_COLOR_BUFFER_BIT); // On efface la surface
glMatrixMode(GL_PROJECTION); // Matrice de projection:
glLoadIdentity; // on la "reset"
gluOrtho2D(0,1,0,1); // projection dans le carré (0,0),(1,1)
glColor3f(1,1,1); // Couleur de tracé: du blanc (RGB=1,1,1)
glBegin(GL_LINE_STRIP); // On commence à faire une suite de lignes
for a:=0 to 100 do
glVertex2f(a/100,T[a]); // On définit la position des sommets de la suite de lignes
glEnd; // Fin de la suite de lignes
finally // Dans tous les cas (même s'il y a eu une erreur):
GlWinControl1.Canvas.UnLock; // fin du tracé (nécessaire pour éviter des problèmes)
end;
end;
Bon moi je remplis le tableau T avec des valeurs aléatoires comprises entre 0 et 1, il faudra que tu mettes à la place de T[a] les valeurs que tu souhaites représenter (éventuellement en les modifiant pour qu'elles soient comprises entre 0 et 1). Une telle procédure s'effectue sans problème à 60 Hz par exemple si la fréquence de rafraichissement de ton écran est de 60 Hz... (mais si ton driver n'a pas activé sa fonction de synchronisation verticale, ce code peut s'exécuter plusieurs centaines de fois par secondes sur une carte graphique standard!).
Si tu veux avoir une idée de la vitesse chez toi, mets un Timer avec Interval=10 dans un nouveau projet, et dans son événement OnExecute mets la procédure précédante. Tu verras que ça va très vite! (en tout cas beaucoup plus vite qu'avec les fonctions de base de TCanvas par exemple). Mais c'est vrai que si tu veux quelque chose qui va encore plus vite (ou plutôt qui ne ralentisse absolument pas le thread de mesure), il faudra faire l'affichage dans un 2ème thread, et protéger tes données avec une section critique par exemple. Mais même si tu utilises une solution multi-thread, OpenGl peut être une bonne solution pour faire des graphiques efficaces et qui vont vite.
cs_Forman
Messages postés
600
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
6 avril 2010
1
29 août 2006 à 01:38
29 août 2006 à 01:38
Je viens de faire le test chez moi:
-Avec un Timer, j'ai une fréquence de 60Hz avec un taux d'occupation du processeur qui oscille entre 0% et 1% de temps à autre (donc autant dire que ça ne consomme quasiment rien en resources!).
-En lançant la procédure dans une boucle infinie, j'obtiens environ 1800Hz (c'est à dire 1800 affichages par seconde!). En mettant 10000 valeurs dans le tableau (c'est déjà beaucoup, non?) ça passe à 300Hz environ. Bon c'est vrai que j'ai une carte vidéo plutôt performante, mais même avec une carte moins puissante tu peux espérer avoir au moins la moitié de ces performances-là. Par conséquent, si tu veux faire qquchose qui affiche une simple courbe, ça peut être envisageable de faire le graphique dans le même thread de cette façon-là.
-Avec un Timer, j'ai une fréquence de 60Hz avec un taux d'occupation du processeur qui oscille entre 0% et 1% de temps à autre (donc autant dire que ça ne consomme quasiment rien en resources!).
-En lançant la procédure dans une boucle infinie, j'obtiens environ 1800Hz (c'est à dire 1800 affichages par seconde!). En mettant 10000 valeurs dans le tableau (c'est déjà beaucoup, non?) ça passe à 300Hz environ. Bon c'est vrai que j'ai une carte vidéo plutôt performante, mais même avec une carte moins puissante tu peux espérer avoir au moins la moitié de ces performances-là. Par conséquent, si tu veux faire qquchose qui affiche une simple courbe, ça peut être envisageable de faire le graphique dans le même thread de cette façon-là.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
29 août 2006 à 04:05
29 août 2006 à 04:05
Oui il est vrai que OpenGL est plus rapide que la GDI ... mais on peu toujours threader pour eviter le freezing.
surtout que c'est mieux pour gerrer la synchro.
<hr size="2" width="100%" />Croc (click me)
surtout que c'est mieux pour gerrer la synchro.
<hr size="2" width="100%" />Croc (click me)
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
29 août 2006 à 09:15
29 août 2006 à 09:15
salut;
si tu ne l'as pas fait je pense qu'il faut surtout mettre un thread pour l'acquisition des données et une pile FIFO
Toutefois le port // présente un défaut pour l'acquisition sous windows
puisqu'il ne bufferise pas les données en réception tu as toujours le
risque de perte entre 2 accès au thread.
la meilleure solution étant de développer un driver qui mette en pile à
chaque interruption du port et ensuite de récupérer les données (c'est
ce que font des sytèmes comme les oscilos sur PC). bien que je préfère
personnellement passer par une carte à microcontroleur qui collecte les
données et me les envoie sur demande du programme soit par la RS soit
par l'USB (qui sont moins fragiles que le port //)
@+
jlen
si tu ne l'as pas fait je pense qu'il faut surtout mettre un thread pour l'acquisition des données et une pile FIFO
Toutefois le port // présente un défaut pour l'acquisition sous windows
puisqu'il ne bufferise pas les données en réception tu as toujours le
risque de perte entre 2 accès au thread.
la meilleure solution étant de développer un driver qui mette en pile à
chaque interruption du port et ensuite de récupérer les données (c'est
ce que font des sytèmes comme les oscilos sur PC). bien que je préfère
personnellement passer par une carte à microcontroleur qui collecte les
données et me les envoie sur demande du programme soit par la RS soit
par l'USB (qui sont moins fragiles que le port //)
@+
jlen
cs_mounjetado
Messages postés
66
Date d'inscription
lundi 13 mars 2006
Statut
Membre
Dernière intervention
4 août 2008
29 août 2006 à 10:31
29 août 2006 à 10:31
Merci à tous!
Je vais potasser tout ça mais avant, je veux préciser que je travaille déjà en multithread, et que, étant autodidacte, je tâtonne un max! Forman, tu en sais qqch puisqu'on a eu l'occasion d'en parler...
Bpn, ceci dit, j'ai eu l'occasion d'aborder des sections critiques, et tout et tout, les piles FIFO idem, mais je suis qd mm largué, vu que je travaille seul sur ce projet.
En outre, il faut que vous sachiez un peu à quoi ça sert et comment mon chef a goupillé ça:
une carte acquisition 32 canaux faite maison car d'après lui ce qu'on trouve ds le commerce ne déclenche pas la mesure sur les 32 canaux synchronisés, mais avec un multiplexage temporel;
la carte est donc SANS µP, et entièrement commandée par le pc (d'où une surconsommation des ressources du PC);
et heureusement j'ai tenu tête à mon chef pour le multithread mais pour le µP (ou µC) que voulez-vous il est buté, et dc j'ai un thread de mesure, et un thread que je destine au calcul ( car il faut moyenner la somme des cycles du signal) avnt de restituer à un theread d'affichage. C'est du moins comme ça que j'envisage la chose...
et pour ce qui est de faire un driver... hum, euh il faudrait déjà qu'on ait les SDK et DDK nécessaires
Bref, j'en conviens, je ne suis pas sorti de l'auberge!
Mais vous me confortez dans mon idée de FIFO et de sections critiques...
Mais une tite qst encore... tout ça, c'est la carte graphique qui le prend en charge? ou mon taux d'échantillonnage va-t-il encore baisser d'après vous? là j'en suis péniblement à 500 mesures par secoonde, si je me plante pas...
Hum bon j'arrête là, sinon je vais lasser! mdr
En tout cas, merci et bonne prog à vous! A très bientôt!
<hr />
si Delphi m'était conté...
Je vais potasser tout ça mais avant, je veux préciser que je travaille déjà en multithread, et que, étant autodidacte, je tâtonne un max! Forman, tu en sais qqch puisqu'on a eu l'occasion d'en parler...
Bpn, ceci dit, j'ai eu l'occasion d'aborder des sections critiques, et tout et tout, les piles FIFO idem, mais je suis qd mm largué, vu que je travaille seul sur ce projet.
En outre, il faut que vous sachiez un peu à quoi ça sert et comment mon chef a goupillé ça:
une carte acquisition 32 canaux faite maison car d'après lui ce qu'on trouve ds le commerce ne déclenche pas la mesure sur les 32 canaux synchronisés, mais avec un multiplexage temporel;
la carte est donc SANS µP, et entièrement commandée par le pc (d'où une surconsommation des ressources du PC);
et heureusement j'ai tenu tête à mon chef pour le multithread mais pour le µP (ou µC) que voulez-vous il est buté, et dc j'ai un thread de mesure, et un thread que je destine au calcul ( car il faut moyenner la somme des cycles du signal) avnt de restituer à un theread d'affichage. C'est du moins comme ça que j'envisage la chose...
et pour ce qui est de faire un driver... hum, euh il faudrait déjà qu'on ait les SDK et DDK nécessaires
Bref, j'en conviens, je ne suis pas sorti de l'auberge!
Mais vous me confortez dans mon idée de FIFO et de sections critiques...
Mais une tite qst encore... tout ça, c'est la carte graphique qui le prend en charge? ou mon taux d'échantillonnage va-t-il encore baisser d'après vous? là j'en suis péniblement à 500 mesures par secoonde, si je me plante pas...
Hum bon j'arrête là, sinon je vais lasser! mdr
En tout cas, merci et bonne prog à vous! A très bientôt!
<hr />
si Delphi m'était conté...
cs_Loda
Messages postés
814
Date d'inscription
vendredi 3 novembre 2000
Statut
Membre
Dernière intervention
30 juillet 2009
3
29 août 2006 à 12:27
29 août 2006 à 12:27
salut,
c'et vrai que la pluspart des cartes d'acuisition du marché ne sont pas syncro. Mais t'en trouve, elle sont juste hors de prix (vu qu'elle ont plusieurs convertisseur AD).
mais suivant ce que tu fais (vitesse, precision voulu), tu peux calculer le décalage et le compenser par soft.
decalage = durée d'acquisition * numero de l'entrée.
/!\ durée d'acquisition <> de l'inverse de la fréquence d'acquisition.
tips: pour le mesurer, met le même signal triangle sur tout tes entrée et regarde tes courbe.
je te conseille tout de même d'acheter un carte plustot que de developper le hard et le driver. si ton chef est tétu, explique lui ce que coût le developpement et le debug (et combien il est prêt a payé pour une meilleur fiabilité et une maintenance facilité)
Pour le driver, si t'en a jamais fait. je te dirais juste : "laisse tomber" c'est pas facile, la doc est casi inexistante (à part le DDK). Mon prof de driver disait que personne ne sait vraiement comment ça marche. De plus, un driver, c'est en C.
Aussi, tu peux être sur que le driver ne marchera que sur une version de Windows.
( En labo, on avait 12 machine identique (matos et version), les exo ne marchaient que sur 3-4 machines et pas toujours les même. On a jamais su pourquoi.)
Sinon, Il existe des bus de terrain specialisé pour les cartes d'acquisition (j'ai pas le nom sous la main, mais c'et genre RS23? ou qqch comme ça) qui te permet de récuper les buffer, de régler des trigger, etc...
Avec des soft genre LabView t'arrive à extraire les donnée sous form de .txt très (hum. disons assez) facilement. De plus, tu peux faire des interface de type "intrument virtuel" avec courbe, bouton, fonction de calcul, etc...
Sinon un petit Up (normal) sur une carte ne cout presque rien. disons inférieur à 50? tout compris. Un kit de developpement peut couter plsu cher. Pour de l'acquisition, prend plustot un DSP et fait une partie du traitement sur la carte. Si tu ne connaîs pas, c'est un peu rude au début, mais le rapport coût/performance est très nettement plus élevé (FFT en un cycle par exemple).
de plus, tu soulage le Up du PC (après tout c'est le principe d'une carte graphique)
bref. en résumer, ne réinvente pas la roue. Achete une carte d'acquisition et, pourquoi pas la piloter toi meme.
A moins que tu n'utilise de OpenGL, la carte graphique ne prendra rien de spécial en charge.
bon courage,
c'et vrai que la pluspart des cartes d'acuisition du marché ne sont pas syncro. Mais t'en trouve, elle sont juste hors de prix (vu qu'elle ont plusieurs convertisseur AD).
mais suivant ce que tu fais (vitesse, precision voulu), tu peux calculer le décalage et le compenser par soft.
decalage = durée d'acquisition * numero de l'entrée.
/!\ durée d'acquisition <> de l'inverse de la fréquence d'acquisition.
tips: pour le mesurer, met le même signal triangle sur tout tes entrée et regarde tes courbe.
je te conseille tout de même d'acheter un carte plustot que de developper le hard et le driver. si ton chef est tétu, explique lui ce que coût le developpement et le debug (et combien il est prêt a payé pour une meilleur fiabilité et une maintenance facilité)
Pour le driver, si t'en a jamais fait. je te dirais juste : "laisse tomber" c'est pas facile, la doc est casi inexistante (à part le DDK). Mon prof de driver disait que personne ne sait vraiement comment ça marche. De plus, un driver, c'est en C.
Aussi, tu peux être sur que le driver ne marchera que sur une version de Windows.
( En labo, on avait 12 machine identique (matos et version), les exo ne marchaient que sur 3-4 machines et pas toujours les même. On a jamais su pourquoi.)
Sinon, Il existe des bus de terrain specialisé pour les cartes d'acquisition (j'ai pas le nom sous la main, mais c'et genre RS23? ou qqch comme ça) qui te permet de récuper les buffer, de régler des trigger, etc...
Avec des soft genre LabView t'arrive à extraire les donnée sous form de .txt très (hum. disons assez) facilement. De plus, tu peux faire des interface de type "intrument virtuel" avec courbe, bouton, fonction de calcul, etc...
Sinon un petit Up (normal) sur une carte ne cout presque rien. disons inférieur à 50? tout compris. Un kit de developpement peut couter plsu cher. Pour de l'acquisition, prend plustot un DSP et fait une partie du traitement sur la carte. Si tu ne connaîs pas, c'est un peu rude au début, mais le rapport coût/performance est très nettement plus élevé (FFT en un cycle par exemple).
de plus, tu soulage le Up du PC (après tout c'est le principe d'une carte graphique)
bref. en résumer, ne réinvente pas la roue. Achete une carte d'acquisition et, pourquoi pas la piloter toi meme.
A moins que tu n'utilise de OpenGL, la carte graphique ne prendra rien de spécial en charge.
bon courage,
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
29 août 2006 à 13:26
29 août 2006 à 13:26
faire un driver n'est pas chose aisée surtout si tu n'en a jamais fait
.Si on utilise le C c'est surtout pour le passage de paramètres mais on
peut très bien utiliser un autre langage (j'avais un info qui les
développait en turbo pascal) mais si ce n'est que pour une application
particulière il est préférable économiquemnt de rechercher d'autres
solutions (le développement et la mise au point sont très longs et par
conséquent couteux) on ne réserve cet exercice que pour développer un
nouveau matériel destiné à la commercialisation.
Il faut savoir également que Windows n'est pas performant en
acquisition ( il n'a pas été conçu pour cela) et l'utilisation de
thread n'est qu'un paliatif: il reste malgré tout monotache et tu ne
pourras guère dépasser le taux que tu obtiens actuellement.
la seule solution est de soulager l'UC en reportant l'acquisition sur une carte spécialisée.
il y a pluieurs solutions suivant ce dont tu as besoin; ceal va des
convertisseurs parallèle/USB (voir chez FTDI pour des couts de 40/50?~
)aux cartes sur bus PCI (je n'ai plus les fournisseurs en tête ) en
passant par des cartes d'acquisition sur port // ou USB (voir chez pico
) à titre d'exemple une carte 2 voies à 20Mech/s livrée avec
drivers dll et composants pour delphi coute environ 400? en comparaison
un développement d'un driver prends environ 300/500h et si l'on prend
un cout moyen horaire de 30/40? c'est au minimum 9000? pour la
rentabilité il n'y a pas photo.
techniquement parlant hormis le fait que windows n'est pas un bon outil
pour l'acquisition il faut aussi savoir que si l'on utilise le port//
le PC doit être à proximité (<1.8m) et que cette liaison est
très sensible aux parasites ; pour l'USB on peut aller jusqu'à 5M ,20m
pour la RS232 et quelques centaines de m en RS485. En milieu industriel
on préfère également les laisons par fibres optiques ou sur réseau
ethernet beaucoup plus fiables bien qu'elles obligent à passer par des
convertisseurs de mode.
@+
jlen
.Si on utilise le C c'est surtout pour le passage de paramètres mais on
peut très bien utiliser un autre langage (j'avais un info qui les
développait en turbo pascal) mais si ce n'est que pour une application
particulière il est préférable économiquemnt de rechercher d'autres
solutions (le développement et la mise au point sont très longs et par
conséquent couteux) on ne réserve cet exercice que pour développer un
nouveau matériel destiné à la commercialisation.
Il faut savoir également que Windows n'est pas performant en
acquisition ( il n'a pas été conçu pour cela) et l'utilisation de
thread n'est qu'un paliatif: il reste malgré tout monotache et tu ne
pourras guère dépasser le taux que tu obtiens actuellement.
la seule solution est de soulager l'UC en reportant l'acquisition sur une carte spécialisée.
il y a pluieurs solutions suivant ce dont tu as besoin; ceal va des
convertisseurs parallèle/USB (voir chez FTDI pour des couts de 40/50?~
)aux cartes sur bus PCI (je n'ai plus les fournisseurs en tête ) en
passant par des cartes d'acquisition sur port // ou USB (voir chez pico
) à titre d'exemple une carte 2 voies à 20Mech/s livrée avec
drivers dll et composants pour delphi coute environ 400? en comparaison
un développement d'un driver prends environ 300/500h et si l'on prend
un cout moyen horaire de 30/40? c'est au minimum 9000? pour la
rentabilité il n'y a pas photo.
techniquement parlant hormis le fait que windows n'est pas un bon outil
pour l'acquisition il faut aussi savoir que si l'on utilise le port//
le PC doit être à proximité (<1.8m) et que cette liaison est
très sensible aux parasites ; pour l'USB on peut aller jusqu'à 5M ,20m
pour la RS232 et quelques centaines de m en RS485. En milieu industriel
on préfère également les laisons par fibres optiques ou sur réseau
ethernet beaucoup plus fiables bien qu'elles obligent à passer par des
convertisseurs de mode.
@+
jlen
cs_Forman
Messages postés
600
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
6 avril 2010
1
29 août 2006 à 13:29
29 août 2006 à 13:29
On peut calculer des FFT dans la carte graphique aussi (véridique!)
Pour un vecteur de 1024 éléments dont on veut la FFT, il faut prévoir une surface OpenGl 1024 x 1 et 2 textures de cette taille-là, et je pense qu'il est aussi possible de le faire en bidimensionnel. Ca va beaucoup plus vite que d'utiliser le CPU...
http://www.cs.unm.edu/~kmorel/documents/fftgpu/
Pour un vecteur de 1024 éléments dont on veut la FFT, il faut prévoir une surface OpenGl 1024 x 1 et 2 textures de cette taille-là, et je pense qu'il est aussi possible de le faire en bidimensionnel. Ca va beaucoup plus vite que d'utiliser le CPU...
http://www.cs.unm.edu/~kmorel/documents/fftgpu/
cs_Loda
Messages postés
814
Date d'inscription
vendredi 3 novembre 2000
Statut
Membre
Dernière intervention
30 juillet 2009
3
29 août 2006 à 14:06
29 août 2006 à 14:06
@Forman:
:O
j'avais jamais pensé cela possible. En fait, je m'étais même jamais poser cette question.
J'ai bien fait de me lever ce matin :)
:O
j'avais jamais pensé cela possible. En fait, je m'étais même jamais poser cette question.
J'ai bien fait de me lever ce matin :)
cs_mounjetado
Messages postés
66
Date d'inscription
lundi 13 mars 2006
Statut
Membre
Dernière intervention
4 août 2008
29 août 2006 à 14:41
29 août 2006 à 14:41
mouaif...
point positif: au moins ça me rassure, l'électronicien que je suis n'est pas encore totalement taré! mais malheureusement je ne tiens pas les cordons de la bourse et mtnt mon chef n'a plus debudget et a reçu un ultimatum de la direction.
point négatif: ici c'est l'article 1 qui prime! à savoir que le chef a toujours raison... comprenne qui peut...
autre point négatif j'ai lu et fait lire à mon chef, un post sur un extrait pathétique de "qui veut gagner des millions"... je lui ai posé la question et il m'a répondu du bout des lèvres que mars tourne autour de la terre! puis que mars tournait autour de la lune!!! que voulez-vous répondre à un soi-disant ingénieur qui vous sort une telle ânerie?
enfin j'en fais mon deuil et j'attends que l'on me cloue au pilori! vais pas me fouler pour une pauvre bande de dégoupillés de la tête.
ah oui j'oubliais! j'utilise les streams aussi. et alors qu'avant j'en utilisais qu'un et que j'affichais ds un tlistbox à raison de plus de 1000 mesures ( pour 32 canaux) à presque 4000 sur 8 canaux (le hard comprend de 1 à 4 modules dont un de base qui transmet 8 canaux sérialisés sur le port parallèle), là j'utilise 2 streams pour en qq sorte double-bufferiser et pouvoir calculer (faire ma courbe moyenne) et afficher, et je divise carrément mon taux de mesure par 2.
en fait, je tiens compte de vos remarques et j'essaie de sortir qqch de valable, mais bon... j'y crois plus.
lol euh... si qqn a besoin d'un électronicien pour bosser correctement... je suis là!!!
merci qd mm pour votre aide
<hr />
si Delphi m'était conté...
point positif: au moins ça me rassure, l'électronicien que je suis n'est pas encore totalement taré! mais malheureusement je ne tiens pas les cordons de la bourse et mtnt mon chef n'a plus debudget et a reçu un ultimatum de la direction.
point négatif: ici c'est l'article 1 qui prime! à savoir que le chef a toujours raison... comprenne qui peut...
autre point négatif j'ai lu et fait lire à mon chef, un post sur un extrait pathétique de "qui veut gagner des millions"... je lui ai posé la question et il m'a répondu du bout des lèvres que mars tourne autour de la terre! puis que mars tournait autour de la lune!!! que voulez-vous répondre à un soi-disant ingénieur qui vous sort une telle ânerie?
enfin j'en fais mon deuil et j'attends que l'on me cloue au pilori! vais pas me fouler pour une pauvre bande de dégoupillés de la tête.
ah oui j'oubliais! j'utilise les streams aussi. et alors qu'avant j'en utilisais qu'un et que j'affichais ds un tlistbox à raison de plus de 1000 mesures ( pour 32 canaux) à presque 4000 sur 8 canaux (le hard comprend de 1 à 4 modules dont un de base qui transmet 8 canaux sérialisés sur le port parallèle), là j'utilise 2 streams pour en qq sorte double-bufferiser et pouvoir calculer (faire ma courbe moyenne) et afficher, et je divise carrément mon taux de mesure par 2.
en fait, je tiens compte de vos remarques et j'essaie de sortir qqch de valable, mais bon... j'y crois plus.
lol euh... si qqn a besoin d'un électronicien pour bosser correctement... je suis là!!!
merci qd mm pour votre aide
<hr />
si Delphi m'était conté...
cs_mounjetado
Messages postés
66
Date d'inscription
lundi 13 mars 2006
Statut
Membre
Dernière intervention
4 août 2008
29 août 2006 à 14:44
29 août 2006 à 14:44
euh forman j'ai que 32 Mo de RAM sur ma carte graphique...
<hr />
si Delphi m'était conté...
<hr />
si Delphi m'était conté...
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
29 août 2006 à 15:09
29 août 2006 à 15:09
je vois que ton igénieur de chef est d'une rare stupidité : si j'en
juge à ce que tu décris le système au départ doit couter plusieurs
centaines voir plusieurs miliers d'euros et vouloir économiser
sur quelques centaines d'euros pour avoir une interface correcte et
performante relève de l'hérésie(je dirais s'il faisiat partie de mon
équipe que cela frise la faute professionnelle fermer le banc). C'est
un peu comme si après avoir mis un superbe moteur dans une voiture on
l'équipait de roues en bois faut pas s'étonner si cela ne tient pas la
route.
sans compter qu'il va faire perdre à coup sur plusieurs miliers d'euros
à la société et sans parler de la crédibilité du service!!
mais bon il faut bien qu'il existe des ânes bâtés.
@+
jlen
juge à ce que tu décris le système au départ doit couter plusieurs
centaines voir plusieurs miliers d'euros et vouloir économiser
sur quelques centaines d'euros pour avoir une interface correcte et
performante relève de l'hérésie(je dirais s'il faisiat partie de mon
équipe que cela frise la faute professionnelle fermer le banc). C'est
un peu comme si après avoir mis un superbe moteur dans une voiture on
l'équipait de roues en bois faut pas s'étonner si cela ne tient pas la
route.
sans compter qu'il va faire perdre à coup sur plusieurs miliers d'euros
à la société et sans parler de la crédibilité du service!!
mais bon il faut bien qu'il existe des ânes bâtés.
@+
jlen
cs_mounjetado
Messages postés
66
Date d'inscription
lundi 13 mars 2006
Statut
Membre
Dernière intervention
4 août 2008
29 août 2006 à 15:33
29 août 2006 à 15:33
jlen lol euh le ban est fermé depuis longtemps et bientôt ce sera le service d'après ce que j'en sais...
côté faute professionnelle il en connais un rayon c'est vrai!
euh, si tu veux, je me permets de t'inviter! tu verras le loustic par toi-mm
mdr non je déconne! tu perdrais ton temps
par contre je peux t'envoyer mon code si tu veux, pour me dire ce que tu en penses?
<hr />
si Delphi m'était conté...
côté faute professionnelle il en connais un rayon c'est vrai!
euh, si tu veux, je me permets de t'inviter! tu verras le loustic par toi-mm
mdr non je déconne! tu perdrais ton temps
par contre je peux t'envoyer mon code si tu veux, pour me dire ce que tu en penses?
<hr />
si Delphi m'était conté...
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
31 août 2006 à 16:32
31 août 2006 à 16:32
ça me fait marrer les gens qui veulent economiser sur de telle choses ...
bonjour je voudrais une lanborghini murcielago GT avec 30% de reduc s'iou plait ... (et une tarte aux concombre en cadeaux).
c'te blague ...
t'es franchement courageux de faire ça ... avec des dirigeants aussi betes et incapables qu'une huitre grillée a l'huile de sojas transgenique.
mais je pense qu'avec les pros qu'il y a ici tu vas pouvoir depatouiller tout ça.
<hr size="2" width="100%" />Croc (click me)
bonjour je voudrais une lanborghini murcielago GT avec 30% de reduc s'iou plait ... (et une tarte aux concombre en cadeaux).
c'te blague ...
t'es franchement courageux de faire ça ... avec des dirigeants aussi betes et incapables qu'une huitre grillée a l'huile de sojas transgenique.
mais je pense qu'avec les pros qu'il y a ici tu vas pouvoir depatouiller tout ça.
<hr size="2" width="100%" />Croc (click me)
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
31 août 2006 à 16:33
31 août 2006 à 16:33
j'oubliais
@forman : pas mal le truc pour la FFT mais il faut avoir une nVidia car Cg oblige...
<hr size="2" width="100%" />Croc (click me)
@forman : pas mal le truc pour la FFT mais il faut avoir une nVidia car Cg oblige...
<hr size="2" width="100%" />Croc (click me)
cs_Forman
Messages postés
600
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
6 avril 2010
1
31 août 2006 à 19:30
31 août 2006 à 19:30
Non, cg fonctionne aussi avec les autres cartes maintenant je crois. Il faut que la carte supporte un des modèles de vertex/pixel shader existants et c'est bon. Je l'ai déjà vu fonctionner avec une ATI.
Ceci dit, je pense que même en opengl quasi-standard (il faut toutefois une ou 2 extensions tels que le blending négatif) il est possible de se débrouiller pour faire de la FFT (après tout ce n'est qu'une suite d'additions avec des coefficients!)
Ceci dit, je pense que même en opengl quasi-standard (il faut toutefois une ou 2 extensions tels que le blending négatif) il est possible de se débrouiller pour faire de la FFT (après tout ce n'est qu'une suite d'additions avec des coefficients!)
cs_mounjetado
Messages postés
66
Date d'inscription
lundi 13 mars 2006
Statut
Membre
Dernière intervention
4 août 2008
1 sept. 2006 à 10:08
1 sept. 2006 à 10:08
f0xi, merci pour ton soutien!!! psychologique et technique...
aux autres aussi!!!
lol si tu veux je te raconterai plein d'anecdotes toutes plus saugrenues, désopilantes et pathétiques les unes que les autres!
bon restons sérieux! là je m'essaie à l'installation de GLScene pour D2005... (eh oui je suis autodidacte, et en POO, et en Delphi, alors bcp de lacunes pour pouvoir me dépatouiller tout seul)
bonne prog à tous, et je reviens vers vous pour vous donner des news de ma régression annoncée
si certains veulent me contacter, vous poouvez me trouver à ces adresses:
[mailto:bernardquesado@wanadoo.fr bernardquesado@wanadoo.fr] (perso et à privilégier)
[mailto:rubick34@hotmail.com rubick34@hotmail.com] ou [mailto:mounjetado@hotmail.fr mounjetado@hotmail.fr] pour tuer 5 minutes ds la bonne humeur
allez je me replonge dans mon univers
<hr />
aux autres aussi!!!
lol si tu veux je te raconterai plein d'anecdotes toutes plus saugrenues, désopilantes et pathétiques les unes que les autres!
bon restons sérieux! là je m'essaie à l'installation de GLScene pour D2005... (eh oui je suis autodidacte, et en POO, et en Delphi, alors bcp de lacunes pour pouvoir me dépatouiller tout seul)
bonne prog à tous, et je reviens vers vous pour vous donner des news de ma régression annoncée
si certains veulent me contacter, vous poouvez me trouver à ces adresses:
[mailto:bernardquesado@wanadoo.fr bernardquesado@wanadoo.fr] (perso et à privilégier)
[mailto:rubick34@hotmail.com rubick34@hotmail.com] ou [mailto:mounjetado@hotmail.fr mounjetado@hotmail.fr] pour tuer 5 minutes ds la bonne humeur
allez je me replonge dans mon univers
<hr />
