Accesso ottimale alla memoria quando si utilizzano le tabelle di ricerca sulla GPU?

Sto esplorando algoritmi isosurface su GPU per un progetto di laurea (concentrandomi in particolare su dati voxel binari in / out piuttosto che su campi con valori reali). Quindi ho un'implementazione CPU di buoni vecchi cubi in marcia in esecuzione su OpenFrameworks, e ora nella fase di provare a portarlo su shader di calcolo GLSL e considerare le insidie prima di immergermi. Ho scritto solo vert e frag shader prima quindi è tutto nuovo per me.

Il mio primo problema è come utilizzare in modo efficiente una tabella di ricerca su dozzine o centinaia di thread in un gruppo di lavoro? Comprendo che una GPU ha diversi tipi di memoria per compiti diversi ma non sono completamente sicura su come ciascuno di essi funzioni o quale tipo usare.

La classica tabella copypasta di Paul Bourke è un array 256 * 16, quindi se si utilizza un tipo di byte scalare questo può presumibilmente essere impacchettato in una trama 4kb o SSBO.

La domanda è: come impedire ai diversi thread di inciamparsi l'un l'altro? Molti cubi in ciascun gruppo di lavoro possono potenzialmente avere la stessa configurazione, quindi tentando di accedere contemporaneamente alla stessa posizione nel buffer. C'è una soluzione alternativa o ottimizzazione per far fronte a questo?

— russ
fonte

Se è una tabella di ricerca di sola lettura, puoi semplicemente usare un buffer / trama. Puoi comprimerlo in uno dei normali formati di trama oppure puoi utilizzare alcune delle più recenti funzionalità di DX11 / OpenGL per avere un formato personalizzato. UAV in terra DX11 o trama / shader_image_load_store in terra OpenGL.

— RichieSams,

Inoltre, dai un'occhiata a questa presentazione: cvg.ethz.ch/teaching/2011spring/gpgpu/cuda_memory.pdf È per CUDA, ma dovrebbe darti un'idea migliore di ciò che sta accadendo sull'hardware sottostante

— RichieSams

Non è una risposta completa, ma minore è la quantità di memoria utilizzata, meglio sarà, poiché sarà più probabile che si inserisca nella cache e abbia meno errori nella cache. Se si hanno valori interpolabili, come se si trasformassero punti in una curva in trame, è possibile verificarlo come un modo per ottenere tabelle di ricerca di curve di qualità superiore con meno memoria: blog.demofox.org/2016/02/22/…

— Alan Wolfe,

Il posto migliore in cui posizionare una tabella di ricerca per uno shader di elaborazione GPU dipende dalle dimensioni della tabella di ricerca e dalla frequenza / coerenza dell'accesso. Nel tuo caso (hai citato 4kb), la memoria locale condivisa sarebbe probabilmente la migliore (supponendo che non sia necessaria questa memoria per altri scopi nello stesso kernel). Questa memoria ha nomi diversi in diverse API, ma è la stessa cosa architetturale e segue le stesse linee guida sulle prestazioni:

CUDA: threadgroup memory condivisa
DirectCompute: memoria condivisa
OpenCL: memoria locale
Metallo: memoria threadgroup
OpenGL: memoria condivisa

Anche l'archiviazione della tabella di ricerca nella memoria globale come buffer di sola lettura può funzionare altrettanto bene, a seconda delle dimensioni della cache della GPU specifica su cui si esegue.

Si noti che presumo che questa sia una tabella di ricerca di sola lettura. Una tabella di ricerca in lettura e scrittura è una bestia completamente diversa e non hai buone opzioni lì.

— GroverManheim
fonte

Ci sono anche casi in cui un buffer di sola lettura farà meglio che archiviare 4kb di dati di sola lettura nella memoria locale condivisa. Ad esempio, memorizzarlo nella memoria locale può significare che esiste una copia univoca dei dati per ogni gruppo di thread. Se il buffer si inserisce nella cache, è possibile che la cache funzioni meglio della memoria locale per i modelli di accesso di sola lettura.

— John Calsbeek,

Grazie per il feedback ragazzi. Ho finito il progetto che stavo usando per ora, e ho finito usando solo una texture tampone r8ui, che ha funzionato abbastanza bene :)

— russ