CUDA ou FPGA pour des calculs graphiques 3D spéciaux?
Je développe un produit avec des calculs graphiques 3D lourds, dans une large mesure les recherches de points et de plages les plus proches. Une optimisation matérielle serait utile. Bien que je sache peu de choses à ce sujet, mon patron (qui n'a aucune expérience logicielle) préconise le FPGA (car il peut être personnalisé), tandis que notre développeur junior préconise le GPGPU avec CUDA, car il est bon marché, chaud et ouvert. Bien que je pense que je manque de jugement sur cette question, je pense que CUDA est la voie à suivre également parce que je m'inquiète de la flexibilité, notre produit est toujours en plein développement.
Donc, reformulant la question, y a-t-il des raisons de choisir le FPGA? Ou existe-t-il une troisième option?
J'ai enquêté sur la même question il y a quelque temps. Après avoir discuté avec des personnes qui ont travaillé sur des FPGA, voici ce que j'obtiens:
- Les FPGA sont parfaits pour les systèmes en temps réel, où même 1 ms de retard peut être trop long. Cela ne s'applique pas dans votre cas;
- Les FPGA peuvent être très rapides, en particulier pour des utilisations bien définies du traitement du signal numérique (par exemple, les données radar), mais les bonnes sont beaucoup plus chères et spécialisées que même les GPGPU professionnels;
- Les FPGA sont assez lourds à programmer. Puisqu'il y a un composant de configuration matérielle à compiler, cela peut prendre des heures. Il semble être plus adapté aux ingénieurs électroniques (qui sont généralement ceux qui travaillent sur les FPGA) qu'aux développeurs de logiciels.
Si vous pouvez faire fonctionner CUDA pour vous, c'est probablement la meilleure option pour le moment. Il sera certainement plus flexible qu'un FPGA.
D'autres options incluent Brook d'ATI, mais jusqu'à ce que quelque chose de grand se produise, il n'est tout simplement pas aussi bien adopté que CUDA. Après cela, il y a toujours toutes les options HPC traditionnelles (clusters de x86/PowerPC/Cell), mais elles sont toutes assez chères.
J'espère que cela pourra aider.
Nous avons fait une comparaison entre FPGA et CUDA. Une chose où CUDA brille si vous pouvez vraiment formuler votre problème de manière SIMD ET accéder à la mémoire fusionnée. Si les accès à la mémoire ne sont pas fusionnés (1) ou si vous avez un flux de contrôle différent dans différents threads, le GPU peut perdre considérablement ses performances et le FPGA peut le surpasser. Une autre chose est lorsque votre opération est de petite taille, mais que vous en avez une énorme quantité. Mais vous ne pouvez pas (par exemple en raison de la synchronisation) ne pas le démarrer en boucle dans un noyau, alors vos temps d'invocation pour le noyau GPU dépassent le temps de calcul.
De plus, la puissance du FPGA pourrait être meilleure (dépend du scénario de votre application, c'est-à-dire que le GPU est seulement moins cher (en termes de Watts/Flop) lorsque son calcul est tout le temps).
Bien sûr, le FPGA a également quelques inconvénients: IO peut en être un (nous avions ici une application où nous avions besoin de 70 Go/s, pas de problème pour le GPU, mais pour obtenir cette quantité de données dans un FPGA vous avez besoin pour la conception conventionnelle de plus de broches que disponible.) Un autre inconvénient est le temps et l'argent.Un FPGA est beaucoup plus cher que le meilleur GPU et les temps de développement sont très élevés.
(1) Les accès simultanés de différents threads à la mémoire doivent se faire à des adresses séquentielles. C'est parfois très difficile à réaliser.
J'irais avec CUDA.
Je travaille dans le traitement d'images et j'essaie des modules complémentaires matériels depuis des années. Nous avons d'abord eu l'i860, puis Transputer, puis DSP, puis le FPGA et la compilation directe sur le matériel.
. les vieilles planches, ou les fabricants de la planche ont fait faillite.
En vous en tenant à quelque chose comme CUDA, vous n'êtes pas lié à un petit fabricant spécialisé de cartes FPGA. Les performances des GPU s'améliorent plus rapidement que celles des CPU et sont financées par les joueurs. Il s'agit d'une technologie grand public qui fusionnera probablement avec les processeurs multicœurs à l'avenir et protégera ainsi votre investissement.
FPGA
- De quoi as-tu besoin:
- Apprenez VHDL/Verilog (et croyez-moi, vous ne le ferez pas)
- Acheter hw pour des tests, des licences sur des outils de synthèse
- Si vous choisissez un bon cadre (par exemple: RSoC )
- Développer le design (et cela peut prendre des années)
- Si vous ne le faites pas:
- DMA, pilote hw, outils de synthèse ultra coûteux
- des tonnes de connaissances sur les bus, la cartographie de la mémoire, la synthèse de matériel
- construire le hw, acheter les noyaux ip
- Développer le design
- Par exemple, une carte FPGA moyenne avec puce Xilinx virtex-6 coûte plus de 3000 $
- Résultat:
- Si vous n'êtes pas payé par le gouvernement, vous n'avez pas assez de fonds.
GPGPU (CUDA/OpenCL)
- Vous avez déjà hw pour tester.
- Comparer avec des choses FPGA:
- Tout est bien documenté.
- Tout est bon marché
- Tout fonctionne
- Tout est bien intégré aux langages de programmation
- Il y a aussi le cloud GPU.
- Résultat:
- Vous devez simplement télécharger sdk et vous pouvez commencer.
Il s'agit d'un vieux fil lancé en 2008, mais il serait bon de raconter ce qui est arrivé à la programmation FPGA depuis lors: 1. C to gates in FPGA est le développement principal pour de nombreuses entreprises avec un gain de temps ÉNORME par rapport à Verilog/SystemVerilog HDL. Dans C to gates, la conception au niveau du système est la partie difficile. 2. OpenCL sur FPGA existe depuis plus de 4 ans, y compris le déploiement en virgule flottante et "cloud" par Microsoft (Asure) et Amazon F1 (API Ryft). Avec la conception du système OpenCL est relativement facile en raison du modèle de mémoire et de l'API très bien définis entre l'hôte et les périphériques de calcul.
Les logiciels doivent simplement en apprendre un peu plus sur l'architecture FPGA pour pouvoir faire des choses qui NE SONT PAS MÊME POSSIBLES avec les GPU et les processeurs pour les raisons d'être à la fois du silicium fixe et de ne pas avoir d'interfaces à large bande (100 Go +) avec le monde extérieur. Il n'est plus possible de réduire la géométrie des puces, ni d'extraire plus de chaleur du paquet de puces uniques sans le faire fondre, donc cela ressemble à la fin de la route pour les puces de paquet unique. Ma thèse ici est que l'avenir appartient à la programmation parallèle de systèmes multi-puces, et les FPGA ont de grandes chances d'être en avance sur le jeu. Consultez http://isfpga.org/ si vous avez des préoccupations concernant les performances, etc.
La solution basée sur FPGA est susceptible d'être beaucoup plus chère que CUDA.
C'est évidemment une question complexe. La question pourrait également inclure le processeur de cellule. Et il n'y a probablement pas une seule réponse qui soit correcte pour d'autres questions connexes.
D'après mon expérience, toute implémentation effectuée de manière abstraite, c'est-à-dire compilée langage de haut niveau vs implémentation de niveau machine, aura inévitablement un coût de performance, en particulier dans une implémentation d'algorithme complexe. Cela est vrai à la fois pour les FPGA et les processeurs de tout type. Un FPGA conçu spécifiquement pour implémenter un algorithme complexe fonctionnera mieux qu'un FPGA dont les éléments de traitement sont génériques, lui permettant une certaine programmabilité à partir des registres de contrôle d'entrée, des entrées/sorties de données, etc.
Un autre exemple général où un FPGA peut être beaucoup plus performant est dans les processus en cascade où les sorties sur processus deviennent les entrées d'un autre et ne peuvent pas être effectuées simultanément. Les processus en cascade dans un FPGA sont simples et peuvent considérablement réduire les besoins d'E/S de mémoire tandis que la mémoire du processeur sera utilisée pour cascader efficacement deux ou plusieurs processus où il existe des dépendances de données.
La même chose peut être dite d'un GPU et d'un CPU. Les algorithmes implémentés en C s'exécutant sur une CPU développée sans tenir compte des caractéristiques de performance inhérentes à la mémoire cache ou au système de mémoire principale ne fonctionneront pas aussi bien que celui implémenté qui le fait. Certes, ne pas tenir compte de ces caractéristiques de performances simplifie la mise en œuvre. Mais à un coût de performance.
N'ayant aucune expérience directe avec un GPU, mais connaissant ses problèmes de performances inhérents au système de mémoire, il sera lui aussi soumis à des problèmes de performances.
Je suis un développeur CUDA avec une très petite expérience avec FPGA: s, mais j'ai essayé de trouver des comparaisons entre les deux.
Ce que j'ai conclu jusqu'à présent:
Le GPU a des performances de pointe beaucoup plus élevées (accessibles). Il a un rapport FLOP/watt plus favorable. Il est moins cher. Il se développe plus rapidement (vous aurez bientôt un "vrai" TFLOP disponible). Il est plus facile de programmer (lire l'article sur cette opinion non personnelle)
Notez que je dis réel/accessible pour faire la distinction avec les chiffres que vous verrez dans une publicité GPGPU.
MAIS le GPU n'est pas plus favorable lorsque vous devez effectuer des accès aléatoires aux données. Nous espérons que cela changera avec la nouvelle architecture Nvidia Fermi qui a un cache l1/l2 en option.
mes 2 cents
Le FPGA ne sera pas favorisé par ceux qui ont un biais logiciel car ils doivent apprendre un HDL ou au moins comprendre systemC.
Pour ceux qui ont un biais matériel, le FPGA sera la première option envisagée.
En réalité, une compréhension ferme des deux est requise et une décision objective peut alors être prise.
OpenCL est conçu pour fonctionner sur FPGA et GPU, même CUDA peut être porté sur FPGA.
Les accélérateurs FPGA et GPU peuvent être utilisés ensemble
Il ne s'agit donc pas de ce qui est mieux l'un ou l'autre. Il y a aussi le débat sur CUDA vs OpenCL
Encore une fois, à moins que vous n'ayez optimisé et comparé les deux à votre application spécifique, vous ne pouvez pas le savoir avec 100% de certitude.
Beaucoup iront simplement avec CUDA en raison de sa nature commerciale et de ses ressources. D'autres iront avec openCL en raison de sa polyvalence.
CUDA a une base de code assez importante d'exemples et un SDK , y compris n back-end BLAS . Essayez de trouver des exemples similaires à ce que vous faites, peut-être aussi en consultant la série de livres GPU Gems , pour évaluer dans quelle mesure CUDA s'adaptera à vos applications. Je dirais d'un point de vue logistique, CUDA est plus facile à utiliser et beaucoup, beaucoup moins cher que n'importe quelle boîte à outils de développement FPGA professionnelle.
À un moment donné, je me suis penché sur CUDA pour la modélisation de simulation de réserves de sinistre. Il existe une assez bonne série de conférences liées au site Web pour l'apprentissage. Sous Windows, vous devez vous assurer que CUDA s'exécute sur une carte sans écran, car le sous-système graphique dispose d'un temporisateur de surveillance qui nuera à tout processus en cours d'exécution pendant plus de 5 secondes. Cela ne se produit pas sous Linux.
Tout mahcine avec deux emplacements PCI-e x16 devrait prendre en charge cela. J'ai utilisé un HP XW9300, que vous pouvez acheter sur ebay à peu de frais. Si vous le faites, assurez-vous qu'il a deux CPU (pas un CPU dual-core) car les emplacements PCI-e vivent sur des bus Hypertransport séparés et vous avez besoin de deux CPU dans la machine pour que les deux bus soient actifs.
D'autres ont donné de bonnes réponses, voulaient juste ajouter une perspective différente. Voici mon enquête papier publiée dans ACM Computing Surveys 2015 (son permalien est ici ), qui compare le GPU avec le FPGA et le CPU sur la métrique d'efficacité énergétique. La plupart des articles rapportent: FPGA est plus économe en énergie que GPU, qui, à son tour, est plus économe en énergie que CPU. Étant donné que les budgets d'alimentation sont fixes (en fonction de la capacité de refroidissement), l'efficacité énergétique du FPGA signifie que l'on peut faire plus de calculs avec le même budget d'alimentation avec FPGA, et ainsi obtenir de meilleures performances avec FPGA qu'avec GPU. Bien sûr, tenez également compte des limitations du FPGA, comme mentionné par d'autres.
Sur quoi déployez-vous? Qui est votre client? Sans même connaître les réponses à ces questions, je n'utiliserais pas de FPGA à moins que vous ne construisiez un système en temps réel et que votre équipe d'ingénieurs électriques/informatiques ait une connaissance des langages de description du matériel tels que VHDL et Verilog. Il y a beaucoup à faire et cela prend un état d'esprit différent de la programmation conventionnelle.
Les FPGA sont tombés en disgrâce dans le secteur HPC parce qu'ils sont une horreur du programme. CUDA est là car il est beaucoup plus agréable à programmer et vous donnera quand même de bonnes performances. J'irais avec ce que la communauté HPC a fait et je le ferais dans CUDA. C'est plus facile, c'est moins cher, c'est plus facile à entretenir.
- Les FPGA sont plus parallèles que les GPU, de trois ordres de grandeur. Alors qu'un bon GPU comporte des milliers de cœurs, le FPGA peut avoir des millions de portes programmables.
- Alors que les cœurs CUDA doivent effectuer des calculs très similaires pour être productifs, les cellules FPGA sont vraiment indépendantes les unes des autres.
- Le FPGA peut être très rapide avec certains groupes de tâches et est souvent utilisé lorsqu'une milliseconde est déjà considérée comme une longue durée.
- Le noyau GPU est bien plus puissant que la cellule FPGA et beaucoup plus facile à programmer. C'est un noyau, qui peut se diviser et se multiplier sans problème lorsque la cellule FPGA n'est capable que d'une logique booléenne assez simple.
- Comme le noyau du GPU est un core, il est efficace de le programmer en C++. Même s'il est également possible de programmer FPGA en C++, il est inefficace (juste "productif"). Des langues spécialisées comme VDHL ou Verilog doivent être utilisées - elles sont difficiles et difficiles à maîtriser.
- La plupart des instincts réels et éprouvés d'un ingénieur logiciel sont inutiles avec FPGA. Vous voulez un pour boucle avec ces portes? De quelle galaxie êtes-vous? Vous devez changer la mentalité d'ingénieur en électronique pour comprendre ce monde.
au plus tard GTC'13, de nombreuses personnes du HPC ont convenu que CUDA est là pour rester. Les FGPA sont encombrants, CUDA devient beaucoup plus mature en supportant Python/C/C++/ARM .. de toute façon, c'était une question datée