2010-09-10 13 views
23

Considerate questa la forma completa della domanda nel titolo: Poiché OpenCL può essere lo standard comune per la programmazione seria delle GPU in futuro (tra gli altri dispositivi di programmazione), perché non quando si programma per OpenGL - in un modo a prova di futuro - utilizzare tutte le operazioni GPU su OpenCL? In questo modo ottieni i vantaggi di GLSL, senza i suoi limiti programmatici.Qual è il punto di GLSL quando c'è OpenCL?

+4

Questo è un po 'come chiedere "Qual è il punto di Safari quando c'è Chrome?" : P –

+0

Il punto principale è che OpenCL non è solo una variante di GLSL; è più ricco a livello di programmazione e più potente nella gestione. –

+1

Una domanda ragionevole. +1 – LarsH

risposta

18

GLSL è OpenGL Shading Language. È inteso, in origine, per il controllo della pipeline grafica.

OpenCL, d'altra parte, è il Open Computing Language. Non controlla la grafica, ma piuttosto il calcolo.

Le due tecnologie si rivolgono a diverse funzionalità e funzionalità.

Detto questo, andando avanti, possono essere davvero pochi motivi per utilizzare GLSL a fini di calcolo. Tuttavia, ad oggi, più fornitori supportano pienamente GLSL di OpenCL, quindi è ancora utile per scopi di calcolo anche se è limitato in quanto non è il suo scopo principale, almeno in questo momento.

+1

Sì, intendevo senza considerare gli obiettivi dichiarati GLSL e OpenCL, OpenCL sembra dare i vantaggi di GLSL in un'interfaccia più potente. C'è qualcosa che OpenCL non può fare che GLSL fa e c'è qualcosa che OpenCL farà in un modo peggiore? –

+1

@Lela: per puro scopo computazionale, al momento, l'unico vero vantaggio (a mia conoscenza) è il supporto di distribuzione e fornitore - GLSL è meglio supportato in natura (da qui il mio ultimo paragrafo). Altrimenti, per puro calcolo, OpenCL è molto più bello di GLSL IMO. –

+0

Beh, sì. Avrei dovuto sottolineare più il "a prova di futuro" di cui ho parlato. L'idea principale di questa domanda riguarda la programmazione per il futuro, mentre molte indicazioni mostrano che OpenCL diventerà uno standard ampiamente supportato. –

4

In futuro OpenCL potrebbe essere in grado di sostituire GLSL. Nel frattempo ci sono ancora alcuni problemi con l'interoperabilità OpenGL, almeno con le implementazioni più importanti (NVidia/ATI).

OpenCL sarà non sostituire completamente OpenGL, però. OpenGL fa molto di più quando si tratta di grafica raster. Le sole primitive grafiche raster in OpenCL sono trame/immagini e non possono affatto rappresentare grafica.

+0

Cosa intendi per "non può rendere"? Per quanto ne so, è possibile implementare tutta la pipeline di OpenGL con OpenCL, ad eccezione del framebuffer (che visualizza elementi sullo schermo). Ciò non significa che non è possibile eseguire il rendering su una texture o forse utilizzare OpenGL * only * solo per allocare un framebuffer che potrebbe essere utilizzato in OpenCL. – Tronic

+3

Sì, potresti farlo, ma sarebbe terribilmente lento. Le GPU hanno hardware dedicato e altamente ottimizzato per il blitting, la rasterizzazione, il blending, la tesselazione e varie altre tipiche operazioni grafiche. OpenCL non fornisce alcun supporto per questo hardware. Questo è ciò che intendevo. – dietr

-3

@dietr: fammi Eco tu qui! l'interoperabilità CL/GL può danneggiare notevolmente le prestazioni generali, specialmente quando si gestisce un numero elevato di buffer di oggetti (> 100, ad esempio). Il sovraccarico del contesto e la mancanza di supporto per strutture di buffer o puntatori ai buffer uccideranno solo le mie app, in modo tale che sto seriamente considerando l'uso di geometria shader per sostituire il mio codice opencl. E non ingannare te stesso, un completo rimpiazzo dell'intero opengl richiederebbe un intero processo di ricodifica che non sarebbe solo molto lungo ma non sarebbe altrettanto vantaggioso. Inoltre, come detto anche dalla gente di qua, Opengl fa molto di più del semplice calcolo delle pipeline. Direi che se intendi usare l'iterop CL/GL, prova a riscrivere il codice su vertex/geometry shader se puoi.

+0

Suppongo che le prestazioni dipendano molto da quello che fai e da come. In genere non condividerai centinaia di buffer, ma solo una manciata al massimo. – dietr

3

GLSL è un "linguaggio di ombreggiatura". Viene utilizzato per il rendering 3D e ha speciali tipi di dati particolarmente utili a tale scopo (ad esempio, vettori di lunghezza-4 e matrici rank-4x4). Gli shader dei vertici e dei frammenti si trovano in una posizione ben definita all'interno della pipeline di rendering e vengono automaticamente attivati ​​sui dati che fluiscono attraverso questa pipeline. Gli shader hanno anche accesso diretto alle matrici di trasformazione e di proiezione della pipeline 3D.

OpenCL è un "linguaggio di calcolo". Non è appositamente progettato per le attività di calcolo che vediamo nel rendering 3D, ma è piuttosto un sottoinsieme di C. OpenCL ha tipi di dati simili ai vettori e matrici in GLSL (float4, float16), ma sono meno convenienti da usare. Inoltre non hai un contesto grafico (che può essere un vantaggio o uno svantaggio), e il kernel OpenCL non risiede in una pipeline di rendering 3D.

Se si desidera che i moduli di elaborazione siano collegati alla pipeline di rendering 3D e attivati ​​dalla pipeline di rendering, utilizzare GLSL. Se si desidera il calcolo generale sulla GPU al di fuori della pipeline di rendering 3D, utilizzare OpenCL.

Ciò non significa che OpenCL non può essere utilizzato per il rendering di grafica 3D. Può.In effetti, è possibile implementare la propria pipeline esclusivamente in OpenCL e quindi copiare il disegno sul framebuffer. Ma se vuoi solo disegnare una grafica 3D, duplicare tutto il lavoro degli ingegneri SGI, Nvidia, Intel e AMD probabilmente non vale la pena. Quindi è più semplice usare semplicemente GLSL e ottenere lo shader collegato a una pipeline OpenGL pronta all'uso e completamente performante. Basti pensare che è stata un'impresa importante scrivere Mesa, l'implementazione OpenGL open source.