Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 684 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
1776
Sur cette carte par exemple tu as une entrée et une sortie HDMI :
https://www.xilinx.com/products/boards-and-kits/1-cfdwic.html
Mais il y a moins cher aussi, tu peux trouver des cartes d'éval avec des petites matrices (souvent avec des interfaces compatibles Arduino) dans les 80$-100$.
https://www.xilinx.com/products/boards-and-kits/cost-optimized-design.html
https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/all-development-kits.html
1777
Citation :
Mais il y a moins cher aussi, tu peux trouver des cartes d'éval avec des petites matrices (souvent avec des interfaces compatibles Arduino) dans les 80$-100$.


Dans ces prix la il existe aussi des cartes avec des puces intégrant à la fois un FPGA et un ou plusieurs coeurs ARM cortes Ax. Ca commence à faire des trucs assez costauds.
1778
Citation de Patrick :

Dans ces prix la il existe aussi des cartes avec des puces intégrant à la fois un FPGA et un ou plusieurs coeurs ARM cortes Ax. Ca commence à faire des trucs assez costauds.

La minized dans le second lien de JimBass fait exactement ça: un cœur ARM-A9 et un FPGA dans la même IC, avec des headers Arduino-compatibles.

Resistance is not futile... it's voltage divided by current

[ Dernière édition du message le 24/11/2018 à 12:22:48 ]

1779
Ha j'avais pas vu ! En effet :bravo:
1780
Oui, et il y en a dans les liens que j'ai posté. Par exemple :
https://www.xilinx.com/products/boards-and-kits/1-odbhjd.html
https://www.intel.com/content/www/us/en/programmable/solutions/partners/partner-profile/terasic-inc-/board/terasic-cyclone-v-soc-starter-kit--de10-nano-.html

Ca peut s'utiliser soit comme un FPGA normal, soit comme un SoC normal (type processeur de tablette ou RasPi), soit surtout comme la combinaison des deux et là ca peut être surpuissant.
1781
x
Hors sujet :
Citation de EraTom :
Du coup ça me donne presque envie d'essayer de coller un FPGA derrière un bus DVI pour détourner son usage et passer des samples sur 24bits dans une image.


LSV ? Le tout premier enregistreur audio numérique professionnel était un module Sony qui fonctionnait en "détournant" l'utilisation des enregistreurs vidéo analogiques U-Matic de la même marque. C'est même la raison pour laquelle le 44.1 kHz est devenu un standard.

http://www.thegreatbear.net/audio-tape/early-digital-tape-recordings-umatic-betamax-video-tape/
1782
Citation de EraTom :
Du coup ça me donne presque envie d'essayer de coller un FPGA derrière un bus DVI pour détourner son usage et passer des samples sur 24bits dans une image.

Avec le DVI, tu auras une sortie, mais pas d'entrées.
Et est-ce que tu as accès au DVI depuis CUDA ? Il me semble que non, mais je ne suis pas bien sûr.
1783
Pas d'entrée, effectivement, mais si c'est pour faire de la synthèse ce n'est pas trop grave.

Avec CUDA tu ne peux pas mapper directement les bus DVI ou HDMI (c'est le problème), par contre tu peux passer un "array CUDA" vers une texture et afficher la texture sur l'écran sans repasser par le CPU. Plus simple à dire qu'à faire mais pas impossible.

Dans une image il y a même suffisamment de pixels pour ne passer qu'un bit par pixel. En changeant le bit de poids faible canal bleu (la couleur où l'oeil le moins sensible) de quelques pixels on garde une image visuellement identique.

Une vidéo à 60Hz, pour un son avec une Fe de 48000Hz, 24 bits stéréo ça fait : 2*24*48000/60 = 38400 pixels à modifier.
Dans une image de 640*480 / 38400 = 8 : tous les 8 pixels il faut chopper le bit de poids faible.

Le flux DVI repart vers un écran et le FPGA se sert au passage pour remplir un buffer contenant le signal audio.

J'ai presque envie d'essayer :-p


Mais je crois que je préfère continuer à jouer avec mon émulateur de MS20, surtout que je viens de faire la nappe de basse de Dreams de Quench par accident et que c'est étrangement addictif...

[ Dernière édition du message le 25/11/2018 à 01:13:32 ]

1784
J'ai regardé le keynote sur SOUL. C'est excellent je trouve. Voir le code DSP comme un shader openGL est une bonne idée. La portabilité est argument très fort. Les possibilités multi langage aussi: GUI en Python et DSP en SOUL, ça devient possible. Si t'as une carte son avec un DSP compatible SOUL, tes plugin tournent dessus. Ca supprime l'enfermement chez un constructeur particulier.

Il y a tellement d'avantages, je suis bluffé par l'idée.

Jul

1785
Sinon, j'avais fait quelques essais avec un FPGA spartan 3 il y a qq années. Franchement, c'est tellement bas niveau que je ne pense pas que le jeu en vaille la chandelle. Les coût de dev sont énormes. J'avais dû coder un CORDIC pour pouvoir faire les log et exp nécessaires aux calculs de fréquence. Sans parler qu'il faut tout faire en virgule fixe. A la fin ça marche, mais c'est vraiment laborieux. Pour moi, le niveau RTL est trop bas. J'avais fini par commencer à développer un mini processeur. Pour obtenir quoi à la fin ? Un DSP embarqué dans le FPGA. Je m'étais arrêté assez rapidement. Bon et puis c'est du proto. Au boulot, il y a une équipe qui fait du RTL, ils sont 4. Il sont 12 dans l'équipe qui fait la vérification :oo: Les bugs coutent cher sur du HW alors autant vérifier avant ! Bon, le FPGA minore un peu ça, vu qu'il est reprogrammable.

Si SOUL décolle, on pourrait tout à fait imaginer des boitiers avec GPU + convertisseurs qui tournent directement le code SOUL.

Jul

1786
Citation de jujupauty :
Pour moi, le niveau RTL est trop bas.


Oui, mais ca évolue vite. Les solutions de high level synthesis ont mis du temps à décoller, mais maintenant ca marche pas mal (avec un surcoût de ressources matérielles par rapport au HDL). D'autres HDL de plus haut niveau comme Chisel sont très en vogue.

Citation de jujupauty :
il faut tout faire en virgule fixe.


Ca aussi ca change. Les derniers blocs DSP de Xilinx supportent des modes flottants, et je crois qu'AlteraIntel fait ca depuis un moment.

Il y a eu au moins 5 générations de circuits depuis le Spartan 3.

Citation de jujupauty :
Bon et puis c'est du proto.


Non, sur beaucoup de marchés de niche le FPGA est dans le produit. Regarde les interfaces audio Antelope, le Waldorf Kyra ou le Novation Peak, pour rester dans le domaine de l'audio.
1787
Pour le proto, je parlais de mon truc :) Je sais que les FPGA finissent dans les produits. :oops2:

Jul

1788
Par contre l'exemple du Peak est intéressant. Je l'avais oublié celui-là. Ca contredit ce que je pense.

Jul

1789
x
Hors sujet :
Citation de jujupauty :
Je sais que les FPGA finissent dans les produits. :oops2:


Désolé, c'est le genre d'a-priori qu'il faut fréquemment que je combatte dans mon job. Comme ceux qui croient encore que les DSP ne se programment qu'en assembleur. Ou ceux qui croient qu'une fois qu'on a tout mis dans le cloud on n'a plus de problème.
1790
x
Hors sujet :

Citation de Jimbass :
ceux qui croient qu'une fois qu'on a tout mis dans le cloud on n'a plus de problème.

Haha!

Resistance is not futile... it's voltage divided by current

1791
Citation :
Sinon, j'avais fait quelques essais avec un FPGA 3 il y a qq années. Franchement, c'est tellement bas niveau que je ne pense pas que le jeu en vaille la chandelle. Les coût de dev sont énormes. J'avais dû coder un CORDIC pour pouvoir faire les log et exp nécessaires aux calculs de fréquence. Sans parler qu'il faut tout faire en virgule fixe. A la fin ça marche, mais c'est vraiment laborieux.
Enfin là l'idée émise c'était plutôt d'utiliser une carte graphique pour les calculs et récupérer le flux audio avec un FPGA plutôt que de devoir renvoyer vers le CPU puis la carte son (et réduire significativement la latence).

FPGA vs DSP, etc. dans un cadre industriel est un débat que je trouve stérile : les deux, et l'on choisi le plus adapté pour récupérer le meilleur des deux mondes. Il n'est pas rare de ventiler les traitements sur les deux technos.
Un ensemble de pré-traitements "simples" réalisés dans un FPGA permettent assez souvent de réduire drastiquement la charge d'un traitement plus complexe réalisé en soft.
1792
Citation de EraTom :
FPGA vs DSP, etc. dans un cadre industriel est un débat que je trouve stérile : les deux, et l'on choisi le plus adapté pour récupérer le meilleur des deux mondes. Il n'est pas rare de ventiler les traitements sur les deux technos.


Oui, mais ce qui est coûteux c'est de déplacer les données de l'un à l'autre, soit par une connexion directe, soit pire encore via une mémoire. Des fois il est préférable de faire (voire de refaire) quelques calculs non optimisés sur un certain type de processeur, plutôt que de faire l'aller-retour entre les processeurs les plus adaptés à chaque étape d'un gros algo.
Maintenant on a des circuits hétérogènes (CPU avec coprocesseur vectoriel, FPGA avec des blocs DSP dans la matrice, FPGA + CPU, etc.) qui réduisent un peu ce souci, mais ca reste un point à considérer.
1793
Je ne dis pas que c'est toujours simple :o)

Mais par exemple pour détecter des transitoires, une première détection "grosse maille" pour écarter des trames qui n'en contiennent pas, ou passer dans un banc de filtres avec une décimation pour chaque bande sur le flux, etc. ça peut s'envisager relativement simplement sur un FPGA avant d'attaquer des algo plus élaborés.
1794
Citation de EraTom :
Enfin là l'idée émise c'était plutôt d'utiliser une carte graphique pour les calculs et récupérer le flux audio avec un FPGA plutôt que de devoir renvoyer vers le CPU puis la carte son (et réduire significativement la latence).


J'avais pô compris :bravo:

Jul

1795
Citation de EraTom :
une première détection "grosse maille" [...] ça peut s'envisager relativement simplement sur un FPGA avant d'attaquer des algo plus élaborés.


Oui, on distingue généralement un traitement "font end" assez simple et systématique mais massif qui s'applique bien sur FPGA ou DSP (ou les deux), puis des traitements "back end" beaucoup plus dynamiques et adaptatifs mais sur des données réduites, exécutés sur CPU.

Enfin c'est ce qui est fait par exemple dans un radar. Mais là on parle de racks entiers ...
1796
Pour préciser, SOUL n'est pas du GPGPU. L'objectif est de déporter vers le DSP qui fait déjà le calcul du son certains autres calculs.

Si en plus on peut faire le calcul de tous les effets sur CPU, oui, ça se fait aussi en calcul graphique quand la carte ne supporte pas tout. C'est lent, mais ça marche et ça permet de débuter. Mais ici l'objectif est de déporter vers des processeurs qui sont plus adaptés, et ça s'appelle un DSP dans 99% des cas.

Perso, j'aime que les DSPs pourraient revenir à la mode et utilisés à leur vrai puissance. On le fait déjà sans le savoir, avec de petits traitements, mais on peut faire plus que ça et avoir un truc à la volée, ben c'est top.

Il y aura un gros travail au niveau du scheduler pour savoir ce qui doit être envoyé où, entre DSP, FPGA, CPU, tout cela se fait déjà ans d'autres domaines, il y aura des défis, mais rien qui nécessitera de la recherche fondamentale, que du temps et de l'argent. Et c'est aussi pour ça que l'effort communautaire est top et je souscris à 100%.

[ Dernière édition du message le 03/12/2018 à 13:08:04 ]

1797
Citation de miles1981 :
Perso, j'aime que les DSPs pourraient revenir à la mode et utilisés à leur vrai puissance.


Oui, mais si déjà on utilisait à bon escient les coprocesseurs vectoriels présents dans les CPU modernes (MMX/SSE/AVX, Altivec, NEON) on gagnerait pas mal.

Citation de miles1981 :
Il y aura un gros travail au niveau du scheduler pour savoir ce qui doit être envoyé où, entre DSP, FPGA, CPU, [...] mais rien qui nécessitera de la recherche fondamentale


Euh, si, de la recherche fondamentale pour ce genre de chose est tout à fait à l'ordre du jour.
Mais il y a déjà un état de l'art académique assez ancien qui attend d'être implémenté dans des produits (commerciaux ou libres).
1798
Citation de Jimbass :
Oui, mais si déjà on utilisait à bon escient les coprocesseurs vectoriels présents dans les CPU modernes (MMX/SSE/AVX, Altivec, NEON) on gagnerait pas mal.

Oui et non. Les CPU actuels font plus que nécessaire. On peut faire mieux, moins cher, plus efficace avec les DSP qu'on a déjà dans nos enceintes. Dès qu'il y a un convertisseur NA/AN, il y a de fortes chances qu'il y a un DSP. Autant l'utiliser, non ?

Citation de Jimbass :
Citation de miles1981 :
Il y aura un gros travail au niveau du scheduler pour savoir ce qui doit être envoyé où, entre DSP, FPGA, CPU, [...] mais rien qui nécessitera de la recherche fondamentale

Euh, si, de la recherche fondamentale pour ce genre de chose est tout à fait à l'ordre du jour.
Mais il y a déjà un état de l'art académique assez ancien qui attend d'être implémenté dans des produits (commerciaux ou libres).

Voilà, c'est ça mon point de vue, pas mal de choses déjà existantes qui peuvent être utilisées avant de chercher des trucs plus alambiqués ;)
1799
Citation de miles1981 :
les DSP qu'on a déjà dans nos enceintes. Dès qu'il y a un convertisseur NA/AN, il y a de fortes chances qu'il y a un DSP. Autant l'utiliser, non ?


Si le fabriquant a mis un DSP, ce n'est certainement pas pour rien : limiteur, filtre actif, protection des HP ... et il a certainement dimensionné la puissance de calcul au plus juste.

x
Hors sujet :
Citation de miles1981 :
Voilà, c'est ça mon point de vue, pas mal de choses déjà existantes qui peuvent être utilisées avant de chercher des trucs plus alambiqués ;)


Certes, mais beaucoup de gens traduisent ca par "plus besoin de faire de la recherche", et c'est une très mauvaise idée. Au contraire, il faut plus d'ingénieurs qui s'intéressent aux publications scientifiques, afin de développer l'application de la recherche.
1800
x
Hors sujet :
Il faut également que l'application soit rentable et viable financièrement. Déporter les calculs vers un DSP ne constitue en rien une révolution scientifique ou technique et pourtant ça ne décolle pas vraiment... la musique sur ordinateur reste encore un marché de niche qui n'attire pas vraiment les gros acteurs.