Questo probabilmente è stato chiesto più e più volte, ma non ho trovato nulla di utile così qui va di nuovo ...Ottimizzazione delle prestazioni OpenGL per il throughput geometria
Nella mia domanda ho bisogno di rendere un gran mesh (una un paio di milioni di triangoli o più) e sto avendo qualche problema a ottenere dei frame rate decenti. La CPU è praticamente inattiva quindi sono decisamente vincolata alla GPU. La modifica della risoluzione non influisce sulle prestazioni, quindi non è frammentata o legata al raster.
La mesh è dinamica (ma localmente statica) quindi non è possibile memorizzare l'intero elemento nella scheda video e renderlo con una chiamata. Per motivi applicativi specifici, i dati vengono memorizzati come un ottetto con voxel nelle foglie, con i mezzi che ottengo fondamentalmente gratuitamente. I dati del vertice sono costituiti da coordinate, normali e colori, senza trame o ombreggiature.
Il mio primo approccio è stato quello di eseguire il rendering di tutto dalla memoria utilizzando un grande VBO STREAM_DRAW, che si è rivelato troppo lento. Il mio pensiero iniziale era che forse stavo sovraccaricando il bus (spingendo ~ 150 MiB per fotogramma), quindi ho implementato uno schema di cache che memorizza la geometria usata di recente per rendere l'oggetto in VBO statici sulla scheda grafica, con ogni VBO che memorizza un paio di 100 KiB a un paio di dati del MiB (la memorizzazione di più per VBO offre più cache thrashing, quindi c'è un compromesso qui). L'immagine sotto è un esempio di come appaiono i dati, in cui tutto ciò che è colorato in rosso viene estratto dai VBO memorizzati nella cache.
Example of the rendered data http://gimaker.users.sourceforge.net/0010.png
Come i numeri che seguono mostrano, non vedo uno spettacolare aumento delle prestazioni quando si utilizza la cache. Per una maglia completamente statica di circa 1 milione di triangoli vengo seguenti frequenze:
- Senza cache: 1.95 Hz
- cache utilizzando matrici vertex: 2.0 Hz (> 75% della maglia è cache)
- caching utilizzando
STATIC_DRAWVBOs: 2.4 Hz
Così le mie domande è come faccio accelerare questo? I.e .:
- Qual è il formato del vertice consigliato per ottenere prestazioni decenti? Utilizzo la memoria interlacciata con posizioni e normali come
GL_FLOATeGL_UNSIGNED_BYTEper i colori, con un byte di riempimento per ottenere l'allineamento di 4 byte (28 byte/totale del vertice). - Se sia possibile utilizzare lo stesso buffer per le normali per tutte le mie caselle (tutte le caselle sono allineate agli assi in modo da poter allocare un buffer normale della dimensione della voce della cache più grande e usarlo per tutti).
- Come sapere quale parte della pipeline è il collo di bottiglia? Non ho una scheda video spettacolare (Intel GM965 con driver Linux open source), quindi è possibile che abbia raggiunto il limite. Quanto posso aspettarmi dal tipico hardware (grafica integrata di 2-3 anni, grafica moderna integrata, grafica moderna discreta)?
- Eventuali altri suggerimenti su come si potrebbe affrontare questo, trappole, ecc
io non sono interessato a risposte che suggeriscono LOD (ho già provato questo), suggerimenti specifici del produttore o utilizzando le funzionalità di OpenGL da tutto ciò in seguito di 1,5.
Le tue primitive sono costituite solo da riquadri allineati agli assi? – Stringer
@Stringer Bell: Sì (ma non necessariamente allineato con gli assi del mondo). – Staffan
Non sono sicuro, ma direi che hai raggiunto il limite della scheda grafica. Ho cercato un po 'su google e sembra che Intel GM965 abbia prestazioni piuttosto basse, soprattutto per i giochi. (Il tuo non è un gioco ma sembra abbastanza "difficile" da renderizzare). Nvidia ha una lista di quanti triangoli le loro carte possono rendere/secondo-forse puoi classificare la tua carta con questa lista per scoprire il limite "teorico". – InsertNickHere