2013-02-26 15 views
6

Ho una base di codice multipiattaforma (iOS e Android) che utilizza un'impostazione di rendering-trama standard. Ogni frame (dopo l'inizializzazione), ha la seguente sequenza:Render-to-texture e sincronizzazione

  1. glBindFramebuffer di un framebuffer con un allegato colore trama
  2. Render roba
  3. *
  4. glBindFramebuffer del framebuffer default (0 su Android, di solito 2 su iOS)
  5. glBindTexture della trama che era l'attaccamento colore per la prima framebuffer
  6. Render utilizzando la texture legato

Su iOS e alcuni dispositivi Android (incluso l'emulatore), questo funziona correttamente e come previsto. Su altri dispositivi (attualmente seduti davanti a un Samsung Galaxy Note in esecuzione 4.0.4), il rendering della seconda fase che utilizza la texture appare "jumpy". Altre animazioni continuano a girare a 60 fps sullo stesso schermo dei bit "jumpy"; la mia conclusione è che le modifiche alla trama di destinazione non sono sempre visibili nel secondo passaggio di rendering.

Per verificare questa teoria, inserisco un glFinish() nel passaggio contrassegnato con un * sopra. Su tutti i dispositivi, ora, questo ha il comportamento corretto. È interessante notare che glFlush() NON risolve il problema. Ma glFinish() è costoso, e non ho visto alcuna documentazione che suggerisce che questo dovrebbe essere necessario.

Quindi, ecco la mia domanda: cosa devo fare quando ho finito di eseguire il rendering su una texture per assicurarmi che la texture più recente sia disponibile nei successivi passaggi di rendering?

+1

Non sembra un comportamento OpenGL ragionevole. Non sono un esperto di ES, ma sono abbastanza sicuro che ES (almeno per le specifiche) non cambi questo comportamento di sincronizzazione di base. Non si poteva fare affidamento su nulla se ciò non fosse valido, come basarsi sulla finitura delle scritture del buffer prima del rendering. Non esistono altri meccanismi di sincronizzazione espliciti per tali operazioni, pertanto la coda dei comandi deve essere sincronizzata correttamente in sequenza. –

+0

E lo prendo, nessun altro l'ha osservato? Potrebbe benissimo essere device/build specifici, ovviamente, ma non è divertente. – addaon

risposta

3

Il codice che descrivi dovrebbe andare bene.

Finché si utilizza un singolo contesto e non si opta per estensioni che riducono il comportamento di sincronizzazione (come EXT_map_buffer_range), allora ogni comando deve apparire come se fosse eseguito esattamente nello stesso ordine specificato in l'API e nel tuo utilizzo dell'API stai eseguendo il rendering sulla trama prima di leggerne il contenuto.

Dato che, probabilmente stai incontrando bug del driver su quei dispositivi. Puoi elencare quali dispositivi stanno riscontrando il problema? Probabilmente troverai hardware o driver comuni.