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

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 123 849 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
281
Surement 8bits mais il y en a trois, un par couleurs... Donc 24bits potentiels de résolution. Il suffit de laisser un signal inchanger (bit 0-7) multiplier les deux autres (bits 8-15 et 16-23) par des porteuses qui vont bien puis de mixer le tout et hop youpi on a du 24 bits. Pour la fréquence ya pas de soucis ce sera bien plus que 96kHz. Grâce à ça on pourrait écouter une image ! :eek2:

Jul

282
C'est plus complique que ca, je pense au niveau du convertisseur.

Citation :
Si biensur, mais si tu veux faire du traitement audio avec, tu es obligé de tranféré entre mémoire video et mémoire, ce qui est relativement lent, donc c'est pour ca que la méthode perds un peu de son interet



En fait, j'ai regarde un ou deux articles recemment a ce propos, pour faire du HPC, des trucs genre LAPACK et cie. Les donnees transferees sont grosses, alors je comprends pas tres bien la nature du pb (je connais rien aux architectures de proc video).
283

Citation : En fait, j'ai regarde un ou deux articles recemment a ce propos, pour faire du HPC, des trucs genre LAPACK et cie. Les donnees transferees sont grosses, alors je comprends pas tres bien la nature du pb (je connais rien aux architectures de proc video).


C'et juste un problème de bande passante du bus AGP je crois, avec le PCIexpress ca devrait plus jouable. De totue facon y'a rien d'impossible, et faire un code de test pour utiliser le GPU en dsp c'est 100 lignes de code avec jack et Cg... mais j'ai jamais pris le temps d'essayer :oops:
284
Euh, j'ai quand même bien l'impression que la 3D reclame autrement plus de bande passante que de l'audio hein ;) Je pense qu'il n'y a aucun pb de bande passante si vous voulez calculer de l'audio sur GPU.
285

Citation : Euh, j'ai quand même bien l'impression que la 3D reclame autrement plus de bande passante que de l'audio hein Je pense qu'il n'y a aucun pb de bande passante si vous voulez calculer de l'audio sur GPU.


heeeuu pas vraiment... le bus AGP (je ne parle aps de PCIe) est fait pour de l'affichage 3D, donc pour y écrire bcp plus que l'on y lit dessus.

https://www-sop.inria.fr/reves/projects/GPUAudio/
c'est court, mais vite lu et assez intéréssant.
286
J'avais pas fait attention au fait qu'il faille également lire les données rapidement sur la carte. Néanmoins, c'est pas tellement le débit du bus qui est en cause (l'AGP va bien assez vite), mais plutôt l'architecture des cartes graphiques qui n'est pas tellement prévue pour qu'on y lise des données. Sur le lien que tu donnes, ils disent que le débit peut être un problème, mais seulement si on doit lire une grande quantité de données en même temps. J'en déduis que pour de l'audio temps réel, ça doit être bon, non ?
287

Citation : Sur le lien que tu donnes, ils disent que le débit peut être un problème, mais seulement si on doit lire une grande quantité de données en même temps. J'en déduis que pour de l'audio temps réel, ça doit être bon, non ?



oue ca doit passer, si tu as linux, comme je le dis avant, faire un test avec jack et Cg ca doit etre très très rapide... (je ne connais pas assez d'algo adio pour faire un test intéssant).
288

Citation :
J'avais pas fait attention au fait qu'il faille également lire les données rapidement sur la carte. Néanmoins, c'est pas tellement le débit du bus qui est en cause (l'AGP va bien assez vite), mais plutôt l'architecture des cartes graphiques qui n'est pas tellement prévue pour qu'on y lise des données.



C'est pareil, je comprends pas tres bien ce point non plus.
289
Et bien, si je dis pas de bétises, le bus AGP est symétrique, c-à-d qu'il y a le même débit montant que descendant. Par contre, je sais que les cartes graphiques ne sont pas franchement conçues pour qu'on y lise des données. A une époque, je voulais utiliser les extensions occlusion_test/occlusion_query, deux fonctions permettant de récupérer des infos de la carte graphique, et bien c'était pas rapide. Je pense que les constructeurs de carte graphique n'avait pas bien jugé l'importance d'avoir un bon débit en lecture.
290
Mon expérience de programmation de jeux video me dit qu'il est par exemple plutôt lent d'aller tester la couleur d'un point dans la mémoire vidéo. Autre exemple, quand on programme un jeux soit on crée chaque frame en mémoire centrale et on la copie une fois terminée dans la mémoire vidéo. Soit on à toute les données nécessaire dnas la mémoire vidéo et on construit l'image en local (OPEN GL & co). Par contre si on copie les sprites ou triangles un par un en mémoire vidéo là c'est la mort des perf... Après l'explication du point de vue architecture, là ??? Peut être, y a-t-il des problèmes d'accès au bus concurents. IL y a sûremet des sémaphores à acquérir pour les accès concurrents à la mémoire vidéo ça c'est presque sûr.

Jul