Quanto tempo impiega OpenGL ad aggiornare effettivamente lo schermo?

Ho una semplice app di test OpenGL in C che disegna cose diverse in risposta all'input chiave. (Mesa 8.0.4, provato con Mesa-EGL e con GLFW, Ubuntu 12.04LTS su un PC con NVIDIA GTX650). I sorteggi sono abbastanza semplici / veloci (tipo di roba a triangolo rotante). Il mio codice di prova non limita deliberatamente il framerate in alcun modo, sembra solo questo:

while (true)
{
    draw();
    swap_buffers();
}

L'ho cronometrato con molta attenzione e trovo che il tempo che intercorre tra una eglSwapBuffers()(o glfwSwapBuffers, stessa cosa) chiamata successiva è di circa 16,6 millisecondi. Il tempo che intercorre tra una chiamata e eglSwapBuffers()l'altra prima di quella successiva è solo un po 'meno, anche se ciò che viene disegnato è molto semplice. Il tempo impiegato dalla chiamata ai buffer di swap è inferiore a 1 ms.

Tuttavia, il tempo dall'app che cambia ciò che sta disegnando in risposta al tasto preme sulla modifica effettivamente visualizzata sullo schermo è> 150 ms (vale circa 8-9 frame). Questo viene misurato con una registrazione della fotocamera dello schermo e della tastiera a 60 fps.

Pertanto, le domande:

1. Dove sono memorizzati i sorteggi tra una chiamata per scambiare i buffer e mostrarli sullo schermo? Perché il ritardo? Sembra che l'app stia disegnando sempre più fotogrammi davanti allo schermo.

2. Cosa può fare un'applicazione OpenGL per provocare un disegno immediato sullo schermo? (ovvero: nessun buffering, basta bloccare fino al completamento dell'estrazione; Non ho bisogno di un throughput elevato, ho bisogno di una bassa latenza)

3. Cosa può fare un'applicazione per fare in modo che l'estrazione immediata di cui sopra avvenga il più velocemente possibile?

4. Come può un'applicazione sapere cosa è effettivamente sullo schermo in questo momento? (Oppure, quanto tempo / quanti frame è il ritardo di buffering corrente?)

Qualsiasi funzione API di disegno chiamata dalla CPU verrà inviata al buffer dell'anello di comando GPU per essere eseguita successivamente dalla GPU. Ciò significa che le funzioni OpenGL sono per lo più funzioni non bloccanti. Quindi la CPU e la GPU lavoreranno in parallelo.

La cosa più importante da notare è che l'applicazione può essere associata a CPU o GPU. una volta chiamato glFinish, la CPU dovrebbe attendere che la GPU completi i suoi comandi di disegno, se la GPU impiega più tempo e può causare l'arresto della CPU, allora le tue applicazioni sono legate alla GPU. Se la GPU termina il disegno dei comandi e la CPU impiega troppo tempo a glFinish, l'applicazione è associata alla CPU.

E nota che c'è una differenza tra glFlushe glFinish.

glFlush: indica che tutti i comandi che sono stati precedentemente inviati al GL devono essere completati a tempo finito.

glFinish: forza il completamento di tutti i precedenti comandi GL. Finish non ritorna fino a quando tutti gli effetti dei comandi precedentemente emessi sullo stato del client e del server GL e sul framebuffer non saranno completamente realizzati. "

glXSwapBuffers esegue un glFlush implicito prima che ritorni. I comandi OpenGL successivi possono essere emessi immediatamente dopo aver chiamato glXSwapBuffers, ma non vengono eseguiti fino al completamento dello scambio del buffer.

Molto probabilmente il tempo di frame effettivo sarà determinato da quale delle due CPU / GPU impiega più tempo per completare il suo lavoro.

OpenGL non aggiorna mai lo schermo, tecnicamente.

Esiste un'API di sistema per finestre separata da GL (ad es. GLX, WGL, CGL, EGL) che esegue questa operazione. Gli swap di buffer che utilizzano queste API generalmente invocano implicitamente glFlush (...)ma in alcune implementazioni (ad esempio il rasterizzatore GDI su Windows) esegue un completo glFinish (...):

    ^{* Sul lato sinistro, è il percorso ICD (hardware) attraverso SwapBuffers (...). Sul lato destro, il percorso GDI (software).}

Se hai VSYNC abilitato e doppio buffering, qualsiasi comando che modifichi il back buffer prima che si verifichi uno swap in sospeso deve arrestarsi fino allo swap. C'è una profondità limitata nella coda dei comandi, quindi questo comando bloccato alla fine causerà un ingorgo nella pipeline. Ciò potrebbe significare che invece di bloccare SwapBuffers (...)l'applicazione in realtà blocca alcuni comandi GL non correlati fino a quando VBLANK non gira. Ciò che si riduce davvero a quanti back buffer hai nella tua catena di swap.

Finché tutti i buffer posteriori sono pieni di frame finiti ma devono essere spostati in avanti, i buffer di swap causeranno implicitamente il blocco. Purtroppo, non esiste alcun modo per controllare esplicitamente il numero di back buffer utilizzati dalla maggior parte delle API del sistema di finestre GL (a parte 0 con buffer singolo o 1 con buffer doppio). Il driver è libero di utilizzare 2 back buffer se lo desidera (triplo buffering), ma non è possibile richiederlo a livello di applicazione usando qualcosa come GLX o WGL.

Presumo che tu abbia familiarità con questo esperimento ?

In sostanza John Carmack stava facendo qualcosa di simile, registrando lo schermo e i pixel di temporizzazione inviati allo schermo. Scoprì che buona parte della latenza proveniva dallo schermo. Altri fattori sono stati il ​​ritardo di input dalla tastiera, i driver video e naturalmente l'esecuzione del programma stesso.