2012-12-05 8 views
6

due parte domanda:OpenGL-OpenCL tempi di trasferimento di interoperabilità + texturing da bitmap

Sto lavorando su un progetto scolastico con il gioco della vita come un veicolo di sperimentare con GPGPU. Sto usando OpenCL e OpenGL per visualizzazioni in tempo reale e l'obiettivo è quello di ottenere questa cosa il più grande e veloce possibile. Dopo la profilatura, trovo che il tempo del frame è dominato da CL Acquisendo e rilasciando i buffer GL, e che il costo del tempo è direttamente proporzionale alla dimensione effettiva del buffer.

1) È normale? Perché dovrebbe essere? Per quanto ne so, il buffer non lascia mai la memoria del dispositivo e l'acquisizione/rilascio di CL agisce come un mutex. OpenCL blocca/sblocca ciascun byte individualmente o qualcosa del genere?

Per ovviare al problema, mi sono ridotto dalla modalità colore RGBA a 24 bit (la modalità colore preferita di OpenGL, a quanto ho capito?) Al colore RGB a 8 bit. Ciò ha comportato un notevole aumento di velocità, ma dopo aver ottimizzato il mio kernel, i tempi di trasferimento stanno nuovamente dominando.

In assenza di idee su come eliminare completamente i tempi di trasferimento (a parte il porting del mio kernel da OpenCL a GLSL, che supererebbe l'ambito originale del progetto), ora ho capito che la mia scommessa migliore è scrivere a una bitmap (al contrario della pixmap a 8 bit attualmente in uso) e quindi utilizzare quella bitmap con un indice di colore per strutturare un quad.

2) Posso strutturare un quad direttamente utilizzando una bitmap? Ho preso in considerazione l'utilizzo di glBitmap per disegnare su un buffer ausiliario e quindi utilizzare questo buffer per strutturare il mio quad, ma preferirei utilizzare un percorso più diretto se ne è disponibile uno.

risposta

2

L'intento progettuale dietro l'acquisizione e il rilascio delle chiamate di interoperabilità CL/GL era che fossero semplicemente trasferimenti di proprietà. Tuttavia, in molte implementazioni iniziali queste stavano facendo copie delle immagini da CL a GL e viceversa.

A meno che non si utilizzino le estensioni degli oggetti di sincronizzazione in OpenCL 1.1, è necessario clFinish prima di rilasciare e glFinish prima dell'acquisizione; Si sarà vedere un sacco di tempo trascorso qui perché tutto il lavoro in coda dovrà finire prima che queste chiamate continuino. Alcune piattaforme puoi usare clFlush invece di clFinish; controlla la documentazione di OpenCL dal tuo fornitore.

Con i driver NVIDIA e AMD più recenti su hardware più o meno recente, vedo le acquisizioni e le chiamate di rilascio che vanno abbastanza velocemente per le immagini di dimensioni video HD.

+0

Eccellente. Sto usando 1.0 (limitazioni hardware) e sono lieto di sapere che questi problemi sono stati risolti. Immagino che quello di cui ho veramente bisogno sia una nuova scheda video. –