Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 119 755 vues
  • 130 followers
1 Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le premier post
751

Citation :
Un truc qui promet beaucoup, c'est qu'alors que pour les CPU, il va falloir programmer en parallele, les GPU ont un modele plus simple pour programmer du numerique (les GPU utilisant les multi core depuis bien plus longtemps que les processeurs). Et la puissance des GPU evolue beaucoup plus vite que les CPU, aussi.



Voilà c'est exact ce que je voulais dire sur la raison de prendre des GPU meme si c'est plus cher ;)
La nouvelle génération de cartes graphiques à architecture unifiée arrive pour la rentrée de septembre , avec la sortie du R600 dans 15 jours arrivera aussi la nouvelle carte de chez nvidia.

Citation : En tout cas, à moins d'une machine virtuelle qui aura de toute manière besoin de savoir d'une manière ou d'une autre ce qu'elle peut paralléliser - et tout en audio ne peut pas être parallélisé -, utiliser le GPU pour tous les VSTs est impossible



Exactement là est le problème. Mais je ne connais pas assez l'architecture des VST pour savoir comment différencier les différents process.
Il faudrait faire un classement de ce qui gagne à être parallélisé, et ce pourquoi c'est plutot un fardeau.
Ensuite il faudrait voir comment transposer le traitement sur les cartes graph.
Il faudrait également regarder si on peut détourner les cartes graphiques pour traiter les samples qui y a en mémoire, pke la plupart des ttes neuves ont la possibilité de garder en mémoire les scènes de jeu vidéo les plus utilisées et calculer uniquement ce qui change. Appliqué à EWQLSO par ex, ca serait puissant :).
Après avoir traité ca, il faudrait voir comment faire l'aiguillage des process en temps réel sans perte importante de perfs à expliquer à la carte qu'est ce qu'elle doit faire. Le point où on peut perdre le plus est de devoir envoyer vers la carte, traduire, et faire revenir l'info.

cptn.io

752
La parallélisation des traitements au niveau global se fait par le séquenceur. Ensuite, au sein des VSTs, c'est à chacun de se débrouiller. Le problème est que même pour une machine virtuelle, il faudra recompiler tous les VSTs pour qu'ils puissent tirer partie des primitives parallèles - idem que pour Python, le calcul est rapide parce qu'on utilise derrière des primitives en C/C++/Fortran -. Donc ça signifie énormément de travail, et comme dit, tous les effets ne sont pas faits pour être parallélisé - un IIR est difficiliment parallélisable, contrairement à un FIR -.
Pour ajouter la partie rester en mémoire, il faudrait un changement complet de standard de plug-in - genre VST4 - et ça n'a d'intérêt que si les GPU ont un intérêt. Pour l'instant, c'est compliqué d'utiliser ça pour un développeur standard, et la précision n'est pas encore au rendez-vous. Ne pas oublier qu'on utilise autre chose que des additions/multiplications dans certains effets aussi, ça limite encore plus l'utilité d'un GPU.
753
Tiens, une serie de slides interessante de Tim Sweeny (le fondateur de Epic Games, la cie derrier Unreal Tournament) sur les limites des langages actuels pour les jeux video.

http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
754
Effectivement c'est intéressant, et très révélateur de ce à quoi sont confrontés les concepteurs de jeux. Les pauvres.. :oo:

Vers la fin, quand il dit:

Citation : If we are to program these devices productively, you are our only hope!


Est-ce que tu sais à qui il s'adresse? A des développeurs d'Haskell?
A man, a plan, a canal : Panama
755
Je suis pas d'accord sur les pauvres... En fait, j'ai vu ce lien poste par un gars qui dit comment il regrette que le premier langage qu'il ait appris soit le C, car selon lui, ca te force l'esprit a voir tout langage comme du C, eg du code qui tourche sur la machine virtuelle C (cad un PDP-11 tres rapide avec beaucoup de memoire).

Perso, je regrette clairement avoir appris le C en premier aussi. Je pense que c'est un des pires langages a apprendre en premier. C'est clairement utile, voire necessaire dans pas mal de cas, puis c'est inherent a Unix, qui reste quand meme la reference en OS.

Le pdf venant d'une universite, on pourrait penser qu'il s'adresse a des membres d'un labo en info.
756
Ca doit dépendre des gens, mais c'est vrai que tout le monde ne peut pas modifier sa manière de penser. Au moins maintenant les maths/infos commencent pas mal par du Caml, puis ensuite font du C - enfin, c'est parfois les 2 de front -, ils ont au moins un peu la philosophie fonctionnelle.
Le truc, c'est que ces slides font porter le gros poids sur le compilateur qui lui passe du fonctionnel - ce qu'il aimerait, en gros -, à de l'impératif en sous-jacent, et donc toutes les vérifications sont faites par l'interpréteur/compilateur.

D'ailleurs, il y a certains points dans la diapo qui me font penser qu'ils devraient penser à essayer Python :D
757
Je pense pas que ce soit possible pour python, le langage est tout simplement trop dynamique pour permettre ce genre de choses. OCAML est certainement beaucoup plus proche a ce niveau la. Mais la taille des communautes n'est pas la meme...
758
Salut les gars et desole si j'interfere dans vos discussions assez haut niveau.
J'ai passé déjà pas mal de temps à chercher et je ne trouve rien qui couvre mon besoin.
Je cherche à developper un petit plug VST (dans un premier temps; peut être AU pour macosx dans un deuxième temps).
juste un petit synthé qui pioche des sons sur la becane pour les rejouer sous des impulsions midi.
J'aurais bien aimé trouver un tuto pour démarrer avec qq petits example de code c++ et visual mais je suis resté bredouille; je suis un peu perplexe devant la multitude des architectures disponibles (csound, portaudio, synthmaker, juce...pfff) et devant le peu de forum ou de retour d'infos sur les usages de ces couches.
Pareil pour l'aspect ihm (Wxwidgets, asseca, ...)
Si quelqu'un peut éclairer ma lanterne sur une façon simple de démarrer
merci
759
Portaudio c'est jouable mais il, te faut visual .net, sinon c'est la misère à faire tourner (et les exemples sont quasi tous sur visual). Mais il te reste à intégrer l'IHM. Chez nous on tourne avec portaudio et QT en interne, mais je ne dirais pas que c'est le plus simple.

Sinon tu as juce, Wolfen a torché un vst assez rapidement avec. Et l'ihm est intégrée.

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

760
Et JUCE gère l'AU aussi ...
Hop, un lien pour aider: http://www.rawmaterialsoftware.com/juce/
My name is john, '_' john.