Consigli sull'accelerazione di OpenGL ES 1.1 su iPhone

Question

Sto lavorando a un'app per iPhone che fa molto affidamento su OpenGL. In questo momento funziona un po 'lento su iPhone 3G, ma sembra scattante sul nuovo iPod Touch 32G. Presumo che questo sia legato all'hardware. Ad ogni modo, voglio che le prestazioni dell'iPhone assomiglino alle prestazioni dell'iPod Touch. Credo che sto facendo un sacco di cose in modo sub-ottimale in OpenGL e mi piacerebbe ricevere consigli su quali miglioramenti mi daranno il massimo.

mio resa scena più o meno così:

• Ripetere 35 volte
  • glPushMatrix
  • glLoadIdentity
  • glTranslate
  • Ripetere 7 volte
    • glBindTexture
    • glVertexPointer
    • glNormalPointer
    • glTexCoordPointer
    • glDrawArrays (GL_TRIANGLES, ...)
  • glPopMatrix

mio Vertex, Normale e texture Coords sono già suddivise.

Quindi, quali passi devo prendere per accelerare questo? Quale passo vorresti provare prima?

Il mio primo pensiero è eliminare tutte quelle chiamate glBindTexture() utilizzando un Atlas texture.

E alcune operazioni con le matrici più efficienti? Capisco che le versioni gl *() non siano troppo efficienti.

E i VBO?

Aggiornamento

ci sono 8260 triangoli. Le dimensioni della trama sono 64 x 64 png. Ci sono 58 diverse texture.

Non ho eseguito gli strumenti.

Aggiornamento 2

Dopo l'esecuzione dello strumento ES OpenGL su iPhone 3G ho trovato che il mio Tiler utilizzo è nel range 90-100%, e il mio Render utilizzo è nel range 30%.

Aggiornamento 3

Texture Atlasing non ha avuto notevole effetto sul problema. Gli intervalli di utilizzo sono ancora come indicato sopra.

Aggiornamento 4

Conversione miei Vertex e normali puntatori a GL_SHORT sembrava migliorare FPS, ma l'utilizzo Tiler è ancora nel range 90% un sacco di tempo. Sto ancora usando GL_FLOAT per le mie coordinate di texture. Suppongo di poterli abbattere a GL_SHORT e salvare altri quattro byte per vertice.

Aggiornamento 5

Conversione coordinate mia texture per GL_SHORT prodotto un ulteriore aumento delle prestazioni. Ora sto ottenendo costantemente> 30 FPS. L'utilizzo del piastrellista è ancora attorno al 90%, ma scende frequentemente nell'intervallo del 70-80%. L'utilizzo del Renderer si aggira attorno al 50%. Suppongo che questo potrebbe avere qualcosa a che fare con il ridimensionamento delle coordinate della texture dalla modalità Matrice GL_TEXTURE.

Sto ancora cercando ulteriori miglioramenti. Mi piacerebbe avvicinarmi a 40 FPS, in quanto è ciò che ottiene il mio iPod Touch ed è liscio come la seta. Se qualcuno sta ancora prestando attenzione, quale altra frutta a bassa attaccatura posso scegliere?

Answer 1

Con un utilizzo piastrellista ancora superiore al 90%, è probabile che ancora vertice di throughput-bound. L'utilizzo del renderer è più elevato perché la GPU sta eseguendo il rendering di più fotogrammi. Se l'obiettivo principale è migliorare le prestazioni su dispositivi precedenti, la chiave deve ancora ridurre la quantità di dati del vertice necessari per ogni triangolo. Ci sono due lati a questo:

Ridurre la quantità di dati per vertice: Ora che tutti i tuoi attributi di vertice sono già GL_SHORT s, la prossima cosa da perseguire è trovare un modo per fare ciò che si vuole utilizzare un minor numero di attributi o componenti. Ad esempio, se si può vivere senza luci speculari, utilizzando l'illuminazione DOT3 invece di OpenGL ES illuminazione a funzione fissa dovrebbe sostituire i 3 cortometraggi (+ 1 breve di imbottitura) per normali con 2 pantaloncini per una texture più coordinate. Come bonus aggiuntivo, sarai in grado di illuminare i tuoi modelli per pixel.

Riduzione del numero di vertici necessari per triangolo: Quando si disegna con triangoli indicizzati, è necessario assicurarsi che gli indici siano ordinati per il massimo riutilizzo. Eseguire la geometria attraverso lo strumento PVRTTriStrip di Imagination Technologies sarebbe probabilmente la soluzione migliore qui.

Answer 2

La prima cosa che vorrei fare è eseguire il profiling degli strumenti sul dispositivo hardware che è lento. Dovrebbe mostrarti abbastanza rapidamente dove sono i colli di bottiglia per il tuo caso particolare.

Aggiornamento dopo strumenti risultati:

This question ha un risultato simile in Strumenti a voi, forse il consiglio è applicabile anche nel tuo caso (riducendo sostanzialmente il numero dei dati vertice)

Answer 3

Se avete solo 58 diversi 64x64 textures, un atlante di texture sembra una buona idea, dato che si inseriscono tutti in una singola trama 512x512 ... se non ti affidi alle modalità di wrap di trama, proverei sicuramente almeno questo.

In che formato sono le trame? Potresti provare a utilizzare una trama PVRTC compressa; Penso che sia meno carico sul piastrellista e sono rimasto piacevolmente sorpreso dalla qualità dell'immagine anche per le trame a 2 bit per pixel. (Buono per immagini naturali, non va bene se stai facendo qualcosa che assomiglia a un videogioco a 8 bit)

Answer 4

Hai guardato la "Guida alla programmazione ES di OpenGL per iPhone OS" nel centro di sviluppo? Ci sono sezioni sulle migliori pratiche per i dati di vertice e dati di trama.

I dati sono formattati per poter utilizzare le strisce triangolari?

In termini di minimo sforzo, la sequenza di modifica per voi sarebbe probabilmente:

• Ridurre vertice attributo size
• VBOs

Si noti che quando si fanno questi, è necessario fare certo che i componenti siano allineati sul loro allineamento nativo, cioè i float o intere sono sui confini a 4 byte, i cortometraggi sono sui confini a 2 byte. Se non lo fai, accumulerà il tuo rendimento. Potrebbe essere utile mapparlo mentalmente digitando l'ordinamento degli attributi come definizione della struct in modo da poter controllare il layout e l'allineamento.

• assicurandosi che i dati vengono spogliati di condividere i vertici
• usando una texture atlante per ridurre struttura swap

Answer 5

La più grande vittoria di programmazione grafica si riduce a questo:

batch, batch , Batch

TextureAtlasing farà la differenza più grande rispetto alla maggior parte qualsiasi altra cosa che si può fare. Cambiare le trame è come fermare un treno in corsa per far salire sempre nuovi passeggeri.

combinare tutte quelle texture in un atlante e tagliare il pareggio chiama giù un sacco.

Questo strumento basato sul web può essere utile: http://zwoptex.zwopple.com/

Answer 6

Per cercare di convertire le texture in formato RGB565 16 bit, vedono questo codice nella veneranda Texture2D.m di Apple, la ricerca di kTexture2DPixelFormat_RGB565

http://code.google.com/p/cocos2d-iphone/source/browse/branches/branch-0.1/OpenGLSupport/Texture2D.m

(questo codice carica PNG e li converte in RGB565 al momento della creazione di struttura, non so se c'è un formato di file RGB565 come tale)

per maggiori informazioni su P VRTC texture compressi (che sembrava il modo migliore di quanto mi aspettassi, quando li ho usati, anche a 2 bit per pixel) vedono campione PVRTextureLoader di Apple:

http://developer.apple.com/iPhone/library/samplecode/PVRTextureLoader/index.html

ha sia il codice per le texture carico PVRTC nella vostra app e anche istruzioni per l'uso di texturetool per convertire i file .png in file .pvr.