Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 123 072 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
731
J'ai vu :)
Mais je viens de voir qu'il y a une version pour FC6 de scipy, et je ne comprend pas trop l'histoire d'ATLAS. J'ai installé atlas avec sse2 puis numpy et il m'a pris la bonne version de la bibliothèque, avec yum :???:

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

732
Oui, j'ai vu ca en checkant sur Fedora Core. J'avoue que je sais pas trop pourquoi il prend atlas. Un des problemes non resolus, c'est comment faire cohabiter mes paquets et ceux des distributions. Le probleme, c'est que je sais pas comment marchent les paquets virtuels sous rpm: tu as plusieurs paquets qui fournissent la meme dependances, par exemple libblas.so (au moins le mien et atlas); comment yum choisit quel paquet installer ? J'en sais rien. La, yum a decide de resoudre la dependance lapack avec atlas. Normalement, je me suis demerde pour prendre les compilos Fortran officiels, pour que les librairies soient compatibles entre elles. Si Atlas est compile correctement, ca devrait marcher (mais la plupart des distributions l'ont fait n'importe comment a un moment ou a un autre; Atlas est pas evident a packager, meme si les nouvelles versions de test sont quand meme beaucoup plus faciles a compiler).

Comme ce sont des librairies dynamiques (je peux te dire que j'en ai chie pour faire ces put* de librairies dynamiques a partir des sources LAPACK, les makefile sont tout pourris, et gcc 4 pour fortran est plutot recalcitrant par rapport), et si c'est bien foutu, normalement, le loader va prendre les version atlas avant les autres.

En fait, sous la plupart des Unix, le loader a meme une capacite dites hwcap, eg il detecte au runtime si ton CPU supporte certains trucs styles sse, sse2, etc..., et charge automatique. Par exemple, sous debian, si tu regardes ce que le loader regarde par defaut pour libblas.so, tu as:



ldconfig -p | grep blas



libgslcblas.so.0 (libc6) => /usr/lib/libgslcblas.so.0

        libgslcblas.so (libc6) => /usr/lib/libgslcblas.so

        libf77blas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libf77blas.so.3

        libf77blas.so.3 (libc6) => /usr/lib/libf77blas.so.3

        libf77blas.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libf77blas.so

        libf77blas.so (libc6) => /usr/lib/libf77blas.so

        libcblas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libcblas.so.3

        libcblas.so.3 (libc6) => /usr/lib/libcblas.so.3

        libcblas.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libcblas.so

        libcblas.so (libc6) => /usr/lib/libcblas.so

        libblas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/atlas/sse2/libblas.so.3

        libblas.so.3 (libc6) => /usr/lib/atlas/libblas.so.3

        libblas.so.3 (libc6) => /usr/lib/libblas.so.3

        libblas.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/atlas/sse2/libblas.so

        libblas.so (libc6) => /usr/lib/atlas/libblas.so


Si tu as le hwcap correspondant (ici le flag correspond a sse2), il va aller prendre libblas.so.4 dans /usr/lib/sse2 au lieu de /usr/lib.
733
Ah oui, ça fait de la complexité en plus pour toi qui t'amuses à faire les paquets :surpris: !
Quand tu te poses la question de pourquoi il prend atlas, c'est par rapport à la version sse2 ? J'imagine que c'est parce que dans les rpm, il n'y aaucun moyen de mettre une affinité selon le processeur ?

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

734
Hello les gens,

Je viens à vous pke c l'endroit le mieux indiqué pour parler de cela :
Je me demande si ca serait possible d'utiliser les stream processor des nouvelles cartes graphiques pour utiliser ca comme des dsp pour faire tourner les vst dessus ... Ca permettrait de pas avoir à dépenser 10000 euros en dsp protools ;)
Est-ce que ca serait possible de faire un host vst qui fasse la "translation" pour que ce soit les CG qui les prenne en charge ???

cptn.io

735

Citation :
Quand tu te poses la question de pourquoi il prend atlas, c'est par rapport à la version sse2



Non. Quand j'ai fait mon truc sur le system de build farms, j'ai package blas et lapack, puis fait dependre numpy et scipy de libblas.so and liblapack.so. Comme plusieurs paquets fournissent ces librairies (entre autre atlas), les outils de gestion de dependance ont leurs algo pour les resoudre, et visiblement, ils sont tous differents. Peut etre que j'ai pas fait mon truc correctement, aussi, je sais pas. Rpm est vraiment chiant a ce niveau, t'as aucun outil pour forcer quoi que ce soit. Sous debian, tu as une policy de packaging tres stricte (style pas de binaire sans man, etc...), avec de nombreux outils pour verifier que ton paquet suit la policy. Sous rpm, rien du tout; comme en plus chaque distribution rpm est differente (genre opensuse, le compilo fortran, c'est gcc-fortran, mais FC, c'est gcc-gfortran....), c'est la merde.

En fait, ce qui fait la qualite de debian, c'est entre autre cette histoire de policy. Ca donne vraiment des paquets de bien meilleure qualite.
736

Citation :
e me demande si ca serait possible d'utiliser les stream processor des nouvelles cartes graphiques pour utiliser ca comme des dsp pour faire tourner les vst dessus ... Ca permettrait de pas avoir à dépenser 10000 euros en dsp protools



D'apres ce que j'ai compris, il y a plusieurs problemes avec le GPGU pour la musique. Le premier probleme, c'est que le bus memoire est pas optmise du tout dans le sens carte -> CPU, et c'est pourtant un parametre crucial, surtout pour le temps reel. Il y a aussi des problemes de precision, je crois.

Sinon, les dsp protools, niveau puissance, faut bien voir que c'est ridicule. N'importe quel CPU recent eclate plus que largement les systems pro tools les plus chers.
737
Tu sais ce que c'est les DSP protools HD ? Parce qu'il y en a 9 par carte, et là moi, comme ça, je peux pas dire si un PC suivra ou non.

Les commandes bas-niveau des GPU (calcul vectoriel, matriciel par exemple) n'ont rien à voir avec les besoins de l'audio.

J'ai voulu me lancer là-dedans à une époque et tous ceux qui ont testé la solution de décharger une partie du traitement sur les GPU m'ont découragé de le faire, vu le peu de performances gagné (par rapport à un upgrade de CPU PC par exemple). Je n'ai plus en tête les raisons du pourquoi du comment, mais en faisant une petite recherche sur le net...

Si tu veux quand même t'amuser tu peux chercher sur le net "GPU shadder".

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

738

Citation :
Tu sais ce que c'est les DSP protools HD ? Parce qu'il y en a 9 par carte, et là moi, comme ça, je peux pas dire si un PC suivra ou non.



J'ai pas suivi les dernieres cartes, c'est vrai; mais si j'en crois P. Davis, qui sait quand meme un minimum de quoi il parle a priori, c'est pas super terrible niveau puissance. En tout cas, pour le meme prix, tu peux avoir plus puissant, ca c'est sur. On sait tres bien quelle est la premiere raison pour les DSP de toute facon.

Pour le GPGPU, j'ai eu la meme vague impression que toi quand je m'y etais interesse quand ca commencait a etre a la mode (2005-2006 ?). C'est tres puissant dans certains cas de calcul scientifique, quand meme:

http://www.thinkingparallel.com/2007/03/25/is-it-time-to-throw-away-your-supercomputers-or-how-foldinghome-is-dominated-by-the-new-kids-in-town/

J'avais un peu discute du truc avec un collegue qui etait dans les jeux video avant, et d'apres lui, le probleme majeur pour le temps reel, c'est le bus memoire qui est tres lent de la carte vers le CPU. Pour les graphiques, tu t'en fous, puisque tout va sur l'ecran et ne repasse jamais par le CPU, mais pour l'audio...
739
Gremlins_4u ce papier peut t'intéresser. Sinon, bah désolé d'être tombé à côté :noidea:
A man, a plan, a canal : Panama
740

Citation :
Tu sais ce que c'est les DSP protools HD ?



J'ai cherche sur le net, pas moyen d'avoir confirmation. Les premiers HD etaient des 56k, je sais pas si c'est toujours le cas. Les plus puissants, d'apres freescale.com, font dans les 250 MMACs. Donc avec 9 DSP, on atteint les 2000 MMAC, ce qui est pas mal, mais a priori n'enfonce pas largement les CPU les plus recents.

Apres, bien sur, c'est plus facile de controler les perfs sur DSP que sur soft "natif", mais bon...