Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Microsoft
Agrandir
Microsoft
Microsoft
(40 avis produit)
Produits 36 36
Actu 7 7
Articles
Tutoriels Tutos 7 7
Avis 40 40
Petites annonces
Forums 199 199

réactions à la news Microsoft plancherait-il sur un logiciel de MAO ?

  • 73 réponses
  • 33 participants
  • 7 089 vues
  • 35 followers
Sujet de la discussion Microsoft plancherait-il sur un logiciel de MAO ?
C’est en tout cas ce que laissent croire les offres d’emploi qui ont été postées par la firme à la fenêtre colorée cet été.

Lire la news
 


Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Afficher le sujet de la discussion
61
Question con : et pendant que le GPU calcule la réverbe à convolution de la mort qui tue, qui c'est qui s'occupe de l'affichage ? :-D

A+ :fleche:

Putain Walter mais qu'est-ce que le Vietnam vient foutre là-dedans ?

62
Citation de kosmix :

... qui c'est qui s'occupe de l'affichage ? :-D


^___^ Je parle bien sur de faire ça avec CUDA/OpenCL, pas GLSL ^^


Citation de alex.d. :

Il y a des DSP bien plus adaptés pour ce type de codes.


C'est très surement vrai, et tes explications m'y font y voir plus clair, et puis sur d'autres forums ils mettent en avant des histoires de traitements parallèles.
Mais reste tout de même des choses qui me chiffonnent dans l'absolu...

- Normalement CUDA/OpenCL sont justement prévu pour faire du calcul autre que des données graphiques, comment ça se fait qu'il y ait pas de traitement DSP "standard" disponibles ??

- Dans le cas d'un plugin "simple", je comprend très bien la problématique (transfert vers le GPU plus lent que de calculer directement au CPU), mais dans le cas de plugin à traitement à la chaine multiples, genre multieffet velu ou ampli guitare (bonjour BIAS FX ^^) ---> à partir du moment ou la data serait déjà en vRAM, c'est pas quand même plus rapide à un moment de faire un maximum de traitements à la chaine dans le GPU avant de renvoyer ça au processeur ?

C'est marrant parce que ça me rappelle les discussions sur les transferts Fast/Chip RAM à l’époque de l'Amiga ---> je peux pas croire que tout ça ne soit pas devenu plus efficace entre temps, même pour des petits blocs ^^
63
Citation de rahow :

- Normalement CUDA/OpenCL sont justement prévu pour faire du calcul autre que des données graphiques, comment ça se fait qu'il y ait pas de traitement DSP "standard" disponibles ??


Un GPU est un processeur conçu pour faire de l'affichage 3D (i.e. de l'algèbre linéaire sur de grosses matrices), qu'on peut détourner de son usage pour faire autre chose que de la 3D. Ça n'en reste pas moins un processeur conçu pour faire de l'algèbre linéaire, c'est-à-dire qu'il est vectoriel sur 1000 à 3000 coeurs. Chaque coeur, pris individuellement, est tout pourri ; c'est leur nombre qui fait leur force. Mais pour ça, il faut que ton calcul soit assez gros et parallélisable. Dans les plugins, il n'y à guère que les plugins avec des convolutions qui pourraient mériter un passage sur GPU. Et encore, une convolution, ça utilise essentiellement une FFT qui a une complexité en O(n.log n), c'est pas encore si bourrin, on n'est pas dans la zone où le GPU sera le plus à l'aise.
Si on regarde un peu ce que ça donne en GPU v.s. CPU sur de la FFT, on a par exemple ceci :
http://www.bealto.com/gpu-fft_benchmarks-1.html
le GPU passe devant le CPU pour une taille de bloc de 2^18. Alors je ne sais pas si psychologiquement tu es prêt à mettre tes buffers ASIO à 262144 (seulement 2.7s de latence à 96kHz) pour pouvoir profiter de ton GPU...

Citation de rahow :

- Dans le cas d'un plugin "simple", je comprend très bien la problématique (transfert vers le GPU plus lent que de calculer directement au CPU), mais dans le cas de plugin à traitement à la chaine multiples, genre multieffet velu ou ampli guitare (bonjour BIAS FX ^^) ---> à partir du moment ou la data serait déjà en vRAM, c'est pas quand même plus rapide à un moment de faire un maximum de traitements à la chaine dans le GPU avant de renvoyer ça au processeur ?


Un GPU n'est pas prévu pour faire les traitement à la chaîne. Il est excessivement mauvais en séquentiel. Il est prévu pour faire les traitement en parallèle. Et pas n'importe quoi en parallèle de n'importe quoi : il est vectoriel, donc tout le monde fait la même opération en même temps sur une donnée différente. Une chaîne d'effets ou n'importe quel modèle dataflow ne rentre pas du tout dans le modèle vectoriel d'un GPU.
64
En résumé c'est une idée de merde :-D

Putain Walter mais qu'est-ce que le Vietnam vient foutre là-dedans ?

65
Citation de alex.d. :
Et pas n'importe quoi en parallèle de n'importe quoi : il est vectoriel, donc tout le monde fait la même opération en même temps sur une donnée différente...


Ah ouai et en fait CUDA (contrairement à ce que je pouvais penser à la base) ne change en fait rien à ça... du coup c'est ou DSP genre Protool HD/UA/Wave, ou rien -____-

Ça reste extrêmement frustrant, parce que malheureusement chacun des constructeur reste dans son coin avec son propre format, alors qu'au moins si y avait un kit global (un 'OpenDSP') qui permettrait la compatibilité entre tous ces fabricants, tous les fabricants pourrait avoir un modèle de carte et les prix baisseraient/se démocratiseraient (et on se ferait moins chier à chercher des solutions alternatives de ce style)
66
Citation de rahow :
Citation de miles1981 :

Meconnaissance totale de l'architecture des GPU...


Un peu quand même, si ^^ Pas au point d'aller moi-même coder des CUDA core il est vrai...

Citation de miles1981 :

... et des algos audio


Oui là c'est vrai... mais si ces fameux algos audio tournent plus vite sur des machines munis de DSP, c'est qu'il doit surement y avoir masse d’opérations de bases ( + - * / ) qu'un processeur standard met trop de cycle à exécuter ^^

Je persiste. Tu n'as aucune connaissance de l'archi d'un GPU et clairement aucune d'un DSP qui n'est qu'un CPU avec quelques instructions dediees (qu'un CPU a maintenant). Croire que tout se qui tourne sur un CPU peut tourner sur un GPU, c'est juste...

Et pourquoi est-ce qu'il y a des DSPs alors que tout pourrait tourner bien plus efficacement sur un processeur actuel (surtout vu les multi-coeurs qu'on a)? C'est le dongle par excellence, et il y a aussi le fait que personne d'autre ne fasse tourner quoique ce soit dessus, donc pas de probleme parce que quelqu'un a decide de multithreader son plugin sans se poser la question des consequences sur les autres.

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

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

[ Dernière édition du message le 18/10/2017 à 12:44:38 ]

67
Citation de miles1981 :

Je persiste. Tu n'as aucune connaissance de l'archi d'un GPU ...

Alex.d. vient justement de remplir mes blancs ^^ Comme je le disais, je pensais à tord que CUDA/OpenCL permettait d'utilisé le GPU comme un CPU, c'est clair que je me suis gouré, mais jamais j'aurais suggéré de dériver des shaders pour faire ça ^^;;

Citation de miles1981 :

et clairement aucune d'un DSP qui n'est qu'un CPU avec quelques instructions dediees (qu'un CPU a maintenant).


Bein il serait peut être temps qu'ils s'en servent de ce "nouveau" jeu d’instruction ---> en fait ce que tu me décris est encore pire ^^;;;

Citation de miles1981 :

Et pourquoi est-ce qu'il y a des DSPs alors... C'est le dongle par excellence, et il y a aussi le fait que personne d'autre ne fasse tourner quoique ce soit dessus...


Donc toi-même tu dis que les cartes DSP ont (aujourd'hui) un faible intérêt technologique et que tout est faisable avec les mèmes perfs sur du processeur X64 normal ?
68
Le probleme des nouveaux jeux d'instructions, c'est qu'il faut tout de meme que ca tourne sur les anciens ! Du coup, par exemple dans Audio ToolKit, pour les filtres travaillant sur plusieurs canaux en parallele, il y a un dispatch automatique en fonction de l'architecture. Le compilateur Intel fait aussi ca. Mais ce n'est pas le cas des compilos classiques (VS, XCode/clang ou gcc) pour le moment. Et donc tant que ce n'est pas generalise, il va falloir utiliser le moins-disant...
Dans mes futurs plugins, je vais sans doute commencer a exiger au moins SSE 4.1. Mais ca coupe d'une partie des utilisateurs potentiels.

Et oui, tout est plus ou moins faisable sur les procs actuels, surtout qu'il n'y a pas de pb de latence a communiquer les infos au DSP par pci-express!

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

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

69
Citation de miles1981 :
Le probleme des nouveaux jeux d'instructions, c'est qu'il faut tout de meme que ca tourne sur les anciens ! Du coup, par exemple dans Audio ToolKit, pour les filtres travaillant sur plusieurs canaux en parallele, il y a un dispatch automatique en fonction de l'architecture. Le compilateur Intel fait aussi ca. Mais ce n'est pas le cas des compilos classiques (VS, XCode/clang ou gcc) pour le moment. Et donc tant que ce n'est pas generalise, il va falloir utiliser le moins-disant...

Seul icc le fait en automatique, mais tu peux le faire toi-même en manuel avec les autres compilos. Il suffit de compiler le kernel avec différents niveaux (SSE, SSE4, AVX, etc.) puis d'y ajouter un frontend qui teste les features du processeur et appelle la bonne version du kernel. C'est assez classique dans les gros codes de calcul.

70
C'est classique, oui, mais lourd. C'est ce que fait ATK pour le multicanal a l'aide de libsimdpp.
Pas pour rien que dans les gros codes de calculs, le compilateur Intel est tres utilise (en plus de ses capacites de vectorization et d'optimisation bien plus avancees).

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

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