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
  • 122 510 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
741
De manière plus générale, ce sont les transferts vers et depuis la CG qui sont problématiques, et pour de l'audio encore plus, puisqu'à priori il y a beaucoup de transferts.
Ensuite, la précision a été améliorée sur certains CG, mais ça ne vaut pas encore la précision des CPUs. De plus, certains unités de calculs sont "encore" en 24 bits, d'autres en 32bits, pas la même précision, d'autant qu'on passe progressivement vers du 64 en audio - cf VST3 -

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

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

742
Vers, je comprends pas tres bien pourquoi vers le GPU pose probleme ? Disons que tu as 50 effets a traiter en meme temps sur un GPU, a disons 100 khz / 32 bits, ca fait donc 20 Mo/s... En video, on va bien au dela. Apres, y a peut etre des problemes de latence.

Le fait que l'on puisse faire du calcul numerique type BLAS/LAPACK/FFT sur GPU me laisserait quand meme supposer que le probleme n'est pas filer beaucoup de donnees au GPU, non ?
743
En regardant sur le net, je vois que ca a pas mal evolue depuis la derniere fois que je m'y suis interesse (y a un an environ): on est plus oblige d'utiliser les pixel shaders, et on peut faire directement en C (ala fftw). La, sur le forum NVIDIA, ils parlent quand meme de chiffres de malades, plusieurs dizaines de Gflop/s sur des FFT de taille raisonables (autour de 10^3). C'et le forum NVIDIA, donc bon, c'est a prendre avec des pincettes, mais quand meme...

http://forums.nvidia.com/lofiversion/index.php?t29951.html

http://developer.download.nvidia.com/compute/cuda/0_8/NVIDIA_CUFFT_Library_0.8.pdf
Mais comme j'y connais rien en carte graphique, je vois pas tres bien les trucs qui coincent.
744
Hello

Effectivement y a eu pas mal de changement depuis qqs temps, Nividia ayant sorti le CUDA qui permet de coder directement en C.
Par rapport à la précision, les chips g80 qui sont les premiers chez Nvidia à avoir la structure unifiée propre à faire ce qu'on veut faire ont la limitation de ne pas avoir de type long si j'ai bien compris, mais les prochaines générations auront cette possibilité.
ATI propose un peu la meme chose avec le CTM mais c'est de la programmation de bien plus bas niveau et ils ont des cartes graphiques modifiées exprès pour ca : https://en.wikipedia.org/wiki/Close_to_Metal .

Les chiffres qu'on te donne sont véridiques, j'ai meme vu des tests approuvés je ne sais plus où qui montraient qu'on peut monter jusqu'au téraflop avec des cartes graphiques en SLI .

Mon problème est plutot que on ne peut pas réécrire tous les vst pour les adapter au GPU.
Il faudrait donc un host vst qui fasse le lien sans induire de pertes de perf trop importantes.
Qu'en pensez vous ? C'est faisable ? Ou le fait de faire de la traduction va n'apporter aucun gain de perfs ?

cptn.io

745
Ce que je comprends pas, c'est comment tu fais pour faire tes millions de fft par seconde: tu dois envoyer tes donnees par paquets de vecteurs, c'est ca ? Genre tu envoies tes millions de fft de taille 1024 par paquets de 100 ou 1000. ?

Citation :
Mon problème est plutot que on ne peut pas réécrire tous les vst pour les adapter au GPU.
Il faudrait donc un host vst qui fasse le lien sans induire de pertes de perf trop importantes.



On pourrait imaginer un truc genre machine virtuelle JIT, cad a compilation a la volee du code pour GPU. C'est d'ailleurs tres proche de ce que fait Mac OS X en utilisant llvm (un compilo JIT pour optimiser les shaders openGL)

http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-August/006492.html

Mais bon, c'est sacrement balaise. Pour qqn d'interesse, ce serait extremement interessant d'essayer ce genre de techniques pour des trucs genre synthes modulaires (j'ai entendu dire que reaktor utilisait aussi certaines techniques JIT, mais evidemment, jamais vu de details).
746
Y'a quand même un truc qui coince : pourquoi faire faire un truc à la CG qui n'est pas prévu d'avance, se prendre le chou à l'extrême, quand un malheureux upgrade de CPU fait la même chose pour moins cher.

Un truc, mais j'ai pas tout lu donc j'ai pu le louper : si le GPU ne prend pas en charge en natif des données AU MOINS 32 bits flottants, faut oublier. En typiquement en vidéo on travaille avec des entiers au plus 16 bits.

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

747

Citation :
Y'a quand même un truc qui coince : pourquoi faire faire un truc à la CG qui n'est pas prévu d'avance, se prendre le chou à l'extrême, quand un malheureux upgrade de CPU fait la même chose pour moins cher.



Ben les ordres de grandeur sont carrement pas les memes :oo: Pour les recentes NVIDIA, on parle quand meme de cents GFLOPS/seconde, voire plus, sur des FFT:

http://www.thinkingparallel.com/2007/02/17/nvidia-releases-cuda-and-reinvents-stream-processing/

Je reciste ce lien (deja donne pour la programmation parallele), parce que c'est assez technique globalement (le site, pas le lien).

Le gros plus de CUDA, c'est que c'est du C, et que tu n'as pas besoin de t'y connaitre en programmation de carte: c'est fondamentalement different de ce que j'avais vu il y a meme pas un an. Typiquement, nvidia propose une FFT avec une API semblable a fftw. L'autre interet, c'est qu'on arrive quand meme a une sacre barriere sur les CPU avec les multi core, alors que les GPU ont une architecture qui aide beaucoup (pleins de threads en parallele de maniere un peu transparante).

Si j'etais pas pauvre, j'acheterais un nouvel ordi avec une carte graphique qui le supporte, ce que j'en ai vu aujourd'hui en parcourant le net me donne bien envie, beaucoup plus que ce que j'avais vu les autres fois...
748
J'avais loupé le truc. 100 GFLOPS c'est énorme, c'est certain.

Par rapport à un core 2 duo qui annonce 50GFLOPS maxi, ça commence à devenir intéressant.

Mais pas si la carte graphique coûte le prix de 4 core 2 duo... ;)

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

749
C'est le principe de plusieurs langages de shaders, d'utiliser du C, et ceci pour nVidia ou ATI. En revanche, à priori la précision des futures cartes d'ATI - celles basées sur le R600 - est meilleure que l'architecture actuelle d'nVidia - G80 -, donc on verra bien.
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 :(

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

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

750
100 Gflops, c'est sur des fft de taille raisonnable. Le core 2 duo, qui est un excellent processeur pour le flottant, il arrivera jamais a ca (et ca depasse de beaucoup les pro tools HD :) ).

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.