Bonsoir,

Je travaille actuellement sur un projet vidéo/son pour un spectacle. Le projet est assez lourd: plusieurs webcam / image / textes / vidéos etc.

Voilà mon problème: mes processeurs sont saturés (entre 85 et 100%), causant des ralentissement et des saccades dans la fenêtre Gem (et plus globalement dans l'ensemble des calculs...)

Voici ma configuration actuelle:
Processeur: double core 2,5Ghtz Intel Celeron / 866 FSB
Ram: 4Go DDR2
Carte Graphique: (vieille...) Sapphire Radeon 256Mo/  Proc 400Htrz
Sys. D'ex: Ubuntu 11.04 / 32 bit


Ma question est la suivante:
Dois-je changer ma carte graphique pour une plus récente?
OU dois-je changer mon processeur?

Car est-ce que Pure Data utilise le processeur pour les calculs OU la carte graphique (et donc dans mon cas la carte graphique étant saturé, il utiliserait donc le processeur?)

Beaucoup de questions.... Merci à ceux qui prendront la peine d'y répondre ( et les autres aussi qui passent par là... )!


Nicolas

Je ne suis pas trop calé en Hardware, mais je peux déjà te dire qu'à ma connaissance, Pd est par défaut mono-thread sur le CPU...
Pour utiliser plusieurs cœurs, il est préférable d'ouvrir plusieurs instances...

Donc si tu n'as qu'une instance... pas la peine de t'acheter un 8 cœurs... :P

Pour le CPU vs GPU, je ne sais pas...
Si ce n'est que les boites [pix_ ] sont exploitées par le CPU...

Bon courage... :)

non ce n'est pas que des pix et loin de là!

Il y a:
des pix_ (video / images .......)
part_ (systeme de particules bien sûr)
et des boîtes textes ...

Comment savoir si ces boîtes là sont géré par le processeur ou la carte graphique?

Ça, je sais :)
[part_ ] et texte2D/3D sont traitées par le GPU.

Si on se limite à GEM, en gros, tout qui relève d'instruction OpenGL qui touche au vectoriel, c'est le GPU...
Dès qu'il y a du bitmap quelque part c'est le CPU qui prend...

Ok génial je te remercie grandement pour cette réponse !!   Donc si je comprends bien, dans un premier temps, changer ma carte graphique pourrait déjà m'aider beaucoup ! Mais si d'autres ont des avis....

Oui, tu devrais lancer idéalement une instance de Pd par fenêtre Gem. J'ai fait uns cript pour ça:

https://gitorious.org/gk-code/gk-code/b … auncher.sh

Pour tester si c'est le CPU, tu peux réduire la taille de tes vidéos par ex en 160 x 120 , et si ça ne saccade plus, tu as trouvé la cause.

Ok merci Oli44...
Désolé de mon ignorance , mais que veut-tu dire par lancer une instance de Pd par fenêtre Gem?

Cela veut dire ourvrir Gem d'abord, puis Pd par la suite? Cela va gagner en performance? Dès que je rentre chez moi je teste ça!

Après de nombreux et laborieux test patch par patch, il s'avère que c'est principalement les systèmes de particules et le fond généré aléatoirement (pdp_plasma, que je convertie ensuite vers Gem avec un pdp2gem) qui sont de loin les plus lourds... Hors comme l'a précisé Olivier, les sytèmes de particule sont gérées par la carte graphique. Je pense que dans mon cas, mon GPU étant saturé, pure data utilise mon CPU en complément qui donc sature lui aussi quand je rajoute les autres patch....  Enfin pour le moment la meilleure explicaton que j'ai trouvé... à moins que qqn en a une meilleure?

Nicolas

- des fois dans des patch complexe seuls quelques objets (une poignée) bouffe quasi toute les ressources, virer ou remplacer ces objets revient à retrouver la souplesse et la performance qui manquait
- comme dit précédemment les pix_* peuvent bouffer pas mal de ressources et empiètent sur le reste car ces instructions sont traitées par le cpu (ce qui n'est pas le cas des instructions traitées par la carte graphique : un ralentissement de la carte graphique a moins d'incidence sur le reste...)
- pd-extended c'est super, mais comme c'est une bonne grosse usine à mazout on a souvent tendance à vouloir tout faire avec, la crémière etc etc, et souvent dans ces situations, nos gentilles machines nous rappellent leur limites...

space47 a écrit:

Cela veut dire ourvrir Gem d'abord, puis Pd par la suite? Cela va gagner en performance? Dès que je rentre chez moi je teste ça!

Non je pense qu'Oli4x4 voulait dire : lancer autant d'instances de pd que tu veux de fenêtre GEM ; cela revient à faire du multithread à la main :)

J'ai remarqué : certains objets pdp_xxx sont bien lourds . Et donc des solutions de remplacement dans Gem sont préférables .
Cela dit avec des applis vidéo ne sachant traiter que sur un processeur il y a moyen de "piper" vers une autre instance . Entre autre avec les vloopbacks (linux only) . C'est ce que j'utilise avec gephex en divisant un patch lourd en 2 instances (et plus sur un quadricoeur) . Il semble que la dernière version de pd-extended intègre cette possibilité . Je n'ai pas testé vu que je suis encore en 0.42.5 . Il y a aussi l'object pdp_vloopback dans pidip 12-29 .
Si les modules vloopback sont pas disponibles dans votre distrib c'est ici (facile à compiler) :
http://www.lavrsen.dk/foswiki/bin/view/ … backDevice

citation :

Non je pense qu'Oli4x4 voulait dire : lancer autant d'instances de pd que tu veux de fenêtre GEM ; cela revient à faire du multithread à la main

Moi, en tout cas, je ne comprends pas... :P
Perso, je ne sais pas ouvrir plusieurs fenêtre GEM avec une seule instance. :/

Olivier a écrit:

Perso, je ne sais pas ouvrir plusieurs fenêtre GEM avec une seule instance. :/

Oui d'où l'idée de lancer plusieurs instances : pour avoir plusieurs fenêtres. Il y avait un début de proposition de code de multi fenetre dans le source de GEM, (par Tigital je crois (ça date)) mais Tigital comme on le sait n'a pu continuer et donc je crois que c'est en stand bye...
@space47 : plus généralement, lancer plusieurs instances de pd permet de distribuer les tâches sur chaque instance et donc de limiter les encombrements notamment du buffer audio. Mais ça c'était avant, aujourd'hui on se servirait plutôt de [pd~] pour ça je suppose.

Hello,

jamais utilisé plusieurs instances Pd jusqu'à maintenant, mais il y a deux threads sur le sujet en ce moment sur le forum Pd hurleurs pour communiquer par UDP ou TCP entre instances :

http://puredata.hurleur.com/sujet-6244-send-netsend
http://puredata.hurleur.com/sujet-6246-tcp-udp

Sinon un lien vers un projet développé en Belgique pour développer des fonctions de traitement d'image Cuda encapsulée dans des blocs Pd :

http://imagine.irisib.be/2011/01/26/int … pure-data/

D'après les auteurs, l'accélération des traitements est énorme, mais reste le problème du transfert des images (qui arrivent sur CPU) vers la carte qui est assez lent. Le gain devient réel si le traitement des images fait appel à plusieurs blocs.

Ok encore merci,

cependant, il n'est pas possible pour moi d'avoir plusieurs fenêtres Gem, tout doit être dans une seule fenêtre...

Utiliser une boîte [pd~] est moins gourmant qu'utiliser une abstraction?
Utiliser une boîte [pd] simule une nouvelle instance, au contraire d'une abstraction qui empile les tâches sur l'instance existante?

Nicolas

salut,

comme tu as uen seule fenêtre gem, tu pourrais cependant

1/ lancer ton pd+gem comme d'hab
2/ lancer une autre instance de pd avec ton pdp et ton pdp bridge qui ensuite pars vers pix_share
3/ récupérer le pix_share dans l'instance de pd avec la fenêtre gem ouverte.

cela t"économise au moins la partie pdp et sa conversion

OK je comprends, et aussi peut-être utiliser une autre instance pd pour faire certains calculs....
ou bien comme le propose thierry, un second ordi pour les calculs....


j'essai dès que je rentre chez moi !

Ouep, c'est ça t'as capté : tu fais bosser plusieurs instances et tu les fais communiquer entre elle une fois le boulot fait. Bon ceci dit il est ultra facile de mettre à genoux n'importe quelle machine récente avec un patch qui en demande beaucoup (qques exemples avec GEM : recopie de buffer à fréquence élevée et haute résolution, effets vidéo sur de la HD, itérations (repeat) nombreuses dans une gemhead, lecture de nombreuses piste vidéos simultanément, chargements fréquents de fichiers qui sont pas en cache, etc etc etc )

space47 a écrit:

OK je comprends, et aussi peut-être utiliser une autre instance pd pour faire certains calculs....
ou bien comme le propose thierry, un second ordi pour les calculs....
!

Euh... non ! en fait tu peux utiliser des sockets pour communiquer entre process qui tournent sur la même machine.

C'est bien ce que cherche à faire la personne dans les threads que je t'ai indiqués, où deux instances de Pd doivent tourner sur les deux proc de sa machine.

Les sockets ont justement été introduites pour communiquer entre process sur une même machine, à côté des pipes qui effectivement sont une spécificité Unix et Linux :

"Les Berkeley sockets, que l'on pourrait traduire par « connecteurs réseau de Berkeley1 », représentent une interface de programmation pour les communications entre processus — Interprocess communication — . Elles ont été introduites pour la première fois dans la version 4.3BSD (1986) de l'UNIX de l'université de Berkeley. Avant leur introduction, le seul mécanisme standard qui permettait à deux processus de communiquer se faisait par l'intermédiaire des pipes."

Tu peux bien entendu utiliser les sockets sous Windows.

Thierry