CUDA o FPGA per calcoli grafici 3D per scopi speciali?

https://stackoverflow.com/questions/317731

11-07-2019
|

Domanda

Sto sviluppando un prodotto con pesanti calcoli grafici 3D, in gran parte il punto più vicino e ricerche di gamma . Alcune ottimizzazioni hardware sarebbero utili. Mentre ne so poco, il mio capo (che non ha esperienza software) sostiene FPGA (perché può essere personalizzato), mentre il nostro sviluppatore junior sostiene GPGPU con CUDA, perché è economico, caldo e aperto. Anche se sento di non avere un giudizio su questa domanda, credo che CUDA sia la strada da percorrere anche perché sono preoccupato per la flessibilità, il nostro prodotto è ancora in forte sviluppo.

Quindi, riformulando la domanda, ci sono dei motivi per scegliere FPGA? O c'è una terza opzione?

Soluzione

Ho analizzato la stessa domanda qualche tempo fa. Dopo aver chattato con persone che hanno lavorato su FPGA, questo è quello che ottengo:

Gli FPGA sono ottimi per i sistemi in tempo reale, dove anche 1ms di ritardo potrebbe essere troppo lungo. Questo non si applica al tuo caso;
Gli FPGA possono essere molto veloci, in particolare per usi ben definiti dell'elaborazione del segnale digitale (ad es. dati radar) ma quelli buoni sono molto più costosi e specializzati anche delle GPGPU professionali;
Gli FPGA sono piuttosto ingombranti da programmare. Poiché è necessario compilare un componente di configurazione hardware, potrebbero essere necessarie ore. Sembra essere più adatto agli ingegneri elettronici (che sono generalmente quelli che lavorano sugli FPGA) rispetto agli sviluppatori di software.

Se riesci a far funzionare CUDA per te, è probabilmente l'opzione migliore al momento. Sarà sicuramente più flessibile di un FPGA.

Altre opzioni includono Brook di ATI, ma fino a quando non succede qualcosa di grosso, semplicemente non viene adottato come CUDA. Dopodiché, ci sono ancora tutte le tradizionali opzioni HPC (cluster di x86 / PowerPC / Cell), ma sono tutte piuttosto costose.

Spero che sia d'aiuto.

Altri suggerimenti

Abbiamo fatto un confronto tra FPGA e CUDA. Una cosa in cui CUDA brilla se puoi davvero formulare il tuo problema in modo SIMD E PUOI accedere alla memoria coalizzata. Se gli accessi alla memoria non sono coalizzati (1) o se si dispone di un flusso di controllo diverso in thread diversi, la GPU può perdere drasticamente le sue prestazioni e l'FPGA può superarlo. Un'altra cosa è quando la tua operazione è veramente piccola, ma ne hai una grande quantità. Ma non puoi (ad esempio a causa della sincronizzazione) non avviarlo in un ciclo in un kernel, quindi i tempi di invocazione per il kernel GPU superano il tempo di calcolo.

Anche la potenza dell'FPGA potrebbe essere migliore (dipende dallo scenario dell'applicazione, ovvero la GPU è solo più economica (in termini di Watt / Flop) quando è sempre in elaborazione).

Offcourse FPGA ha anche alcuni inconvenienti: IO può essere uno (avevamo un'applicazione qui dove avevamo bisogno di 70 GB / s, nessun problema per la GPU, ma per ottenere questa quantità di dati in un FPGA è necessario per la progettazione convenzionale più pin di quelli disponibili). Un altro svantaggio è il tempo e il denaro. Un FPGA è molto più costoso della migliore GPU e i tempi di sviluppo sono molto alti.

(1) Gli accessi simultanei da thread diversi alla memoria devono essere indirizzati a indirizzi sequenziali. Questo a volte è davvero difficile da raggiungere.

Vorrei andare con CUDA.
Lavoro nell'elaborazione delle immagini e provo componenti aggiuntivi hardware da anni. Prima avevamo l'i860, poi il Transputer, poi il DSP, poi l'FPGA e la compilazione diretta all'hardware.
Ciò che è inevitabilmente accaduto è che quando le schede hardware erano davvero debug e affidabili e il codice era stato portato su di esse - le CPU normali erano avanzate per batterle, o l'architettura della macchina di hosting era cambiata e non potevamo usare le vecchie schede, o i creatori del consiglio fallirono.

Attaccando a qualcosa come CUDA non sei legato a un piccolo produttore specializzato di schede FPGA. Le prestazioni delle GPU stanno migliorando più velocemente delle CPU e sono finanziate dai giocatori. È una tecnologia tradizionale e quindi probabilmente si fonderà con CPU multi-core in futuro e proteggerà così il tuo investimento.

FPGA

Cosa ti serve:
- Impara VHDL / Verilog (e fidati di me non lo farai)
- Acquista hw per test, licenze su strumenti di sintesi
- Se scegli un buon framework (ad esempio: RSoC )
  - Sviluppa design (e può richiedere anni)
- In caso contrario:
  - DMA, driver hw, strumenti di sintesi ultra costosi
  - tonnellate di conoscenza su bus, mappatura della memoria, sintesi hw
  - crea l'hw, acquista i core ip
  - Sviluppa design
Ad esempio, una scheda pcie FPGA media con chip Xilinx virtex-6 costa più di 3000 $
Risultato:
- Se non sei pagato dal governo non hai abbastanza fondi.

GPGPU (CUDA / OpenCL)

Hai già hw su cui testare.
Confronta con roba FPGA:
- Tutto è ben documentato.
- Tutto a buon mercato
- Tutto funziona
- Tutto è ben integrato nei linguaggi di programmazione
Esiste anche un cloud GPU.
Risultato:
- Devi solo scaricare sdk e puoi iniziare.

È probabile che la soluzione basata su FPGA sia molto più costosa di CUDA.

Ovviamente questa è una domanda complessa. La domanda potrebbe anche includere il processore cellulare. E probabilmente non c'è una sola risposta che sia corretta per altre domande correlate.

Nella mia esperienza, qualsiasi implementazione eseguita in modo astratto, cioè linguaggio compilato di alto livello rispetto all'implementazione a livello di macchina, avrà inevitabilmente un costo in termini di prestazioni, specialmente in una complessa implementazione dell'algoritmo. Questo vale sia per FPGA che per processori di qualsiasi tipo. Un FPGA progettato specificamente per implementare un algoritmo complesso funzionerà meglio di un FPGA i cui elementi di elaborazione sono generici, consentendogli un grado di programmabilità da registri di controllo di input, I / O di dati ecc.

Un altro esempio generale in cui un FPGA può avere prestazioni molto più elevate è rappresentato dai processi a cascata in cui gli output di processo diventano input per un altro e non possono essere eseguiti contemporaneamente. I processi a cascata in un FPGA sono semplici e possono ridurre drasticamente i requisiti di I / O di memoria, mentre la memoria del processore verrà utilizzata per mettere in cascata due o più processi in cui vi sono dipendenze di dati.

Lo stesso si può dire di una GPU e una CPU. Gli algoritmi implementati nell'esecuzione C su una CPU sviluppata indipendentemente dalle caratteristiche intrinseche delle prestazioni della memoria cache o del sistema di memoria principale non funzioneranno come uno implementato. Certo, non considerare queste caratteristiche prestazionali semplifica l'implementazione. Ma a un costo di prestazione.

Non avendo esperienza diretta con una GPU, ma conoscendo i suoi intrinseci problemi di prestazioni del sistema di memoria, anche questo sarà soggetto a problemi di prestazioni.

Questo è un vecchio thread iniziato nel 2008, ma sarebbe bene raccontare cosa è successo alla programmazione FPGA da allora: 1. C to gate in FPGA è lo sviluppo principale per molte aziende con un enorme risparmio di tempo rispetto a Verilog / SystemVerilog HDL. In C to gate Il design a livello di sistema è la parte difficile. 2. OpenCL su FPGA è disponibile da 4+ anni inclusi virgola mobile e "cloud" distribuzione da parte di Microsoft (Asure) e Amazon F1 (API Ryft). Con OpenCL la progettazione del sistema è relativamente semplice grazie al modello di memoria e all'API molto ben definiti tra i dispositivi host e di calcolo.

Gli esperti di software devono solo imparare qualcosa sull'architettura FPGA per poter fare cose che NON SONO ANCHE POSSIBILI con GPU e CPU per motivi sia di silicio fisso che di non avere interfacce a banda larga (100 Gb +) verso il mondo esterno. Non è più possibile ridurre la geometria del chip, né estrarre più calore dal pacchetto a chip singolo senza scioglierlo, quindi questa sembra la fine della strada per i chip a pacchetto singolo. La mia tesi qui è che il futuro appartiene alla programmazione parallela di sistemi multi-chip e che gli FPGA hanno grandi possibilità di essere all'avanguardia. Dai un'occhiata a http://isfpga.org/ se hai dubbi sulle prestazioni, ecc.

CUDA ha una base di codice abbastanza consistente di esempi e un SDK , incluso < a href = "http://www.nvidia.com/content/cudazone/cuda_sdk/Linear_Algebra.html" rel = "nofollow noreferrer"> un back-end BLAS . Prova a trovare alcuni esempi simili a quello che stai facendo, magari guardando anche il GPU Gems serie di libri, per valutare quanto CUDA si adatta alle tue applicazioni. Direi che dal punto di vista logistico, CUDA è più facile da lavorare e molto, molto più economico di qualsiasi toolkit professionale di sviluppo FPGA.

A un certo punto ho esaminato CUDA per la modellazione della simulazione della riserva di sinistro. C'è una buona serie di lezioni collegate al sito per l'apprendimento. Su Windows, devi assicurarti che CUDA sia in esecuzione su una scheda senza display poiché il sottosistema grafico ha un timer watchdog che annulla qualsiasi processo in esecuzione per più di 5 secondi. Ciò non si verifica su Linux.

Qualsiasi mahcine con due slot PCI-e x16 dovrebbe supportare questo. Ho usato un HP XW9300, che puoi prendere su eBay abbastanza a buon mercato. In tal caso, assicurarsi che abbia due CPU (non una CPU dual-core) poiché gli slot PCI-e vivono su bus Hypertransport separati e sono necessarie due CPU nella macchina per avere entrambi i bus attivi.

Sono uno sviluppatore CUDA con un'esperienza molto ridotta con FPGA: s, tuttavia ho cercato di trovare confronti tra i due.

Quello che ho concluso finora:

La GPU ha prestazioni di picco (accessibili) di gran lunga più elevate Ha un rapporto FLOP / watt più favorevole. È più economico Si sta sviluppando più velocemente (molto presto avrai letteralmente disponibile un TFLOP "reale"). È più facile programmare (leggi l'articolo su questa opinione non personale)

Nota che sto dicendo reale / accessibile per distinguere dai numeri che vedrai in uno spot GPGPU.

MA la GPU non è più favorevole quando è necessario effettuare accessi casuali ai dati. Si spera che questo cambi con la nuova architettura Nvidia Fermi che ha una cache l1 / l2 opzionale.

i miei 2 centesimi

FPGA non sarà favorito da coloro che hanno una propensione al software in quanto devono imparare un HDL o almeno capire systemC.

Per quelli con un pregiudizio hardware FPGA sarà la prima opzione considerata.

In realtà è necessaria una solida conoscenza di entrambi & amp; allora può essere presa una decisione obiettiva.

OpenCL è progettato per funzionare su FPGA e amp; GPU, anche CUDA può essere portato su FPGA.

FPGA e amp; Gli acceleratori GPU possono essere usati insieme

Quindi non si tratta di cosa sia meglio l'uno o l'altro. C'è anche il dibattito su CUDA vs OpenCL

Ancora una volta, a meno che tu non abbia ottimizzato & amp; confrontato entrambi con la tua specifica applicazione che non puoi conoscere con certezza al 100%.

Molti andranno semplicemente con CUDA a causa della sua natura commerciale & amp; risorse. Altri andranno con openCL per la sua versatilità.

Su cosa stai distribuendo? Chi è il tuo cliente? Senza nemmeno conoscere le risposte a queste domande, non utilizzerei un FPGA a meno che non si stia costruendo un sistema in tempo reale e non ci siano ingegneri elettrici / informatici nel proprio team che abbiano conoscenza dei linguaggi di descrizione dell'hardware come VHDL e Verilog. C'è molto da fare e richiede uno stato d'animo diverso rispetto alla programmazione convenzionale.

Gli FPGA sono caduti in disgrazia nel settore HPC perché sono un horrorterror da programmare. CUDA è perché è molto più bello da programmare e ti darà comunque delle buone prestazioni. Vorrei andare con quello che la comunità HPC ha seguito e farlo in CUDA. È più facile, è più economico, è più gestibile.

Altri hanno dato buone risposte, volevo solo aggiungere una prospettiva diversa. Ecco il mio sondaggio paper pubblicato su ACM Computing Surveys 2015 (il suo rapporto è < : //dl.acm.org/citation.cfm? doid = 2658850.2636342 "rel =" nofollow "> qui ), che confronta GPU con FPGA e CPU sulla metrica dell'efficienza energetica. La maggior parte dei documenti riporta: FPGA è più efficiente dal punto di vista energetico rispetto alla GPU, che a sua volta è più efficiente dal punto di vista energetico rispetto alla CPU. Poiché i budget di potenza sono fissi (a seconda della capacità di raffreddamento), l'efficienza energetica di FPGA significa che si possono fare più calcoli all'interno dello stesso budget di potenza con FPGA, e quindi ottenere prestazioni migliori con FPGA che con GPU. Ovviamente, tengono conto anche delle limitazioni FPGA, come menzionato da altri.

Gli FPGA sono più paralleli delle GPU, di tre ordini di grandezza. Mentre una buona GPU include migliaia di core, FPGA può avere milioni di gate programmabili.
Sebbene i core CUDA debbano eseguire calcoli molto simili per essere produttivi, le celle FPGA sono veramente indipendenti l'una dall'altra.
FPGA può essere molto veloce con alcuni gruppi di attività e viene spesso utilizzato laddove un millisecondo è già visto come una lunga durata.
Il core GPU è molto più potente della cella FPGA e molto più facile da programmare. È un nucleo, può dividere e moltiplicare nessun problema quando la cellula FPGA è in grado solo di una logica booleana piuttosto semplice.
Poiché il core GPU è un core , è efficiente programmarlo in C ++. Anche se è anche possibile programmare FPGA in C ++, è inefficiente (solo "produttivo"). Devono essere utilizzate lingue specializzate come VDHL o Verilog: sono difficili e difficili da padroneggiare.
La maggior parte degli istinti veri e provati di un ingegnere del software sono inutili con FPGA. Vuoi un per loop con queste porte? Di quale galassia sei? È necessario cambiare la mentalità dell'ingegnere elettronico per capire questo mondo.

al più tardi GTC'13 molte persone HPC hanno concordato che CUDA è qui per restare. Gli FGPA sono ingombranti, CUDA sta diventando molto più maturo supportando Python / C / C ++ / ARM .. in entrambi i casi, era una domanda datata

La programmazione di una GPU in CUDA è decisamente più semplice. Se non hai alcuna esperienza con la programmazione di FPGA in HDL, sarà quasi sicuramente una sfida per te, ma puoi comunque programmarli con OpenCL che è un po 'simile a CUDA. Tuttavia, è più difficile da implementare e probabilmente molto più costoso della programmazione di GPU.

Quale è più veloce?

La GPU funziona più velocemente, ma FPGA può essere più efficiente.

La GPU ha il potenziale di funzionare a una velocità superiore a quella che FPGA può mai raggiungere. Ma solo per algoritmi che sono particolarmente adatti a questo. Se l'algoritmo non è ottimale, la GPU perderà molte prestazioni.

FPGA invece funziona molto più lentamente, ma è possibile implementare hardware specifico per i problemi che sarà molto efficiente e farà cose in meno tempo.

È un po 'come mangiare la tua zuppa con una forchetta molto velocemente rispetto a mangiarla con un cucchiaio più lentamente.

Entrambi i dispositivi basano le loro prestazioni sulla parallelizzazione, ma ognuna in un modo leggermente diverso. Se l'algoritmo può essere granulato in molti pezzi che eseguono le stesse operazioni (parola chiave: SIMD), la GPU sarà più veloce. Se l'algoritmo può essere implementato come una lunga pipeline, l'FPGA sarà più veloce. Inoltre, se si desidera utilizzare il virgola mobile, FPGA non ne sarà molto soddisfatto :)

Ho dedicato la mia tesi di laurea a questo argomento.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow