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.
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. –