Esiste un limite al numero di contesti di rendering OpenGL che è possibile creare contemporaneamente?

Question

L'applicazione My .Net Winforms crea tre contesti di rendering OpenGL nella mia finestra principale, quindi consente all'utente di visualizzare altre finestre in cui ogni finestra presenta altri due contesti di rendering (utilizzando uno splitter). Intorno al 26 ° contesto di rendering, le cose iniziano ad andare VERAMENTE lente. Invece di impiegare alcuni millisecondi per eseguire il rendering di un frame, il nuovo contesto di rendering richiede tra 5 e 10 secondi. Funziona ancora, solo DAVVERO LENTAMENTE! E OpenGL NON restituisce alcun errore (glGetError).

Le altre finestre funzionano correttamente. Solo i nuovi contesti di rendering dopo un certo numero di rallentamenti. Se chiudo quelle finestre, è tutto a posto - fino a quando non riapuro abbastanza finestre per superare il limite. Ogni contesto di rendering ha il suo thread e ognuno usa un semplice shader. Il rallentamento sembra accadere quando carico una texture. Ma la dimensione della trama non ha alcun effetto sul numero di contesti che posso creare, né la dimensione della finestra OpenGL.

Sono in esecuzione su schede nVidia e lo vedo su diverse GPU con diverse quantità di memoria e diverse versioni di driver. Qual è l'accordo? Esiste un limite al numero di contesti di rendering che un'applicazione può creare?

Qualcun altro ha un'applicazione con un sacco di contesti di rendering che vanno nello stesso momento?

Answer 1

La soluzione migliore è che non esiste una risposta reale a questa domanda. Probabilmente dipende da alcune limitazioni interne del driver, dall'hardware persino del sistema operativo. Qualcosa che dovresti provare a verificare è il numero di unità di texture disponibili usando glGet(GL_MAX_TEXTURE_UNITS) ma potrebbe essere o meno indicativo.

Una soluzione comune per evitare questo è creare più finestre all'interno di un singolo contesto piuttosto che più contesti in una singola finestra. Non dovrebbe essere troppo difficile unire i due contesti che condividono una finestra in un singolo contesto con due finestre e una sorta di widget UI da utilizzare come splitter. Molteplici finestre sono una storia diversa e potresti voler considerare di ripensare completamente la progettazione dell'interfaccia utente se esiste una reale necessità di 26 finestre OpenGL separate.
È difficile per me, in questo momento, pensare a un vero caso d'uso dell'interfaccia utente che in realtà richiederebbe l'utilizzo simultaneo di 26 finestre OpenGL diverse. forse un'altra opzione è creare un pool di detti contesti 5-10 e riutilizzarli solo nelle finestre (schede?) che sono attualmente visibili all'utente. Non l'ho provato, ma dovrebbe essere possibile creare un contesto all'interno di una finestra semplice che non contiene nient'altro e quindi spostare quella finestra dalla finestra padre alla finestra padre per qualsiasi finestra di livello superiore in cui sia necessaria.

EDIT -
Beh, in realtà non è così difficile pensarne uno. L'ultimo Chrome (9.x.x), che supporta WebGL, potrebbe voler aprire molte schede ognuna con un contesto WebGL ... Mi chiedo se gestiscono questo in alcun modo. Ho appena provato e ha esaurito la memoria dopo 13 schede ... Sarebbe davvero un buon controllo anche per te, per vedere se qualcosa di sbagliato stai facendo o se chrome e firefox (4.0.x-beta) hanno lo stesso problema

Answer 2

Data la natura diversa dei driver OpenGL, la soluzione migliore è probabilmente controllare il comportamento dei driver principali (AMD/Intel/NVIDIA/MS Software Render) e al primo avvio eseguire un test. Per esempio. se puoi vedere che NVIDIA rallenta sempre come hai visto, quindi esegui un ciclo rapido fino a quando non vedi dove si trova il limite su quella macchina (o meglio, la carta). Non è molto divertente, ma penso che sia piuttosto difficile superare i limiti in modo affidabile.

In altre parole, "la migliore scommessa" è proprio come una risposta precedente, non si può sapere in anticipo.

Answer 3

Come diceva correttamente Nathan Kidd, il limite è specifico dell'implementazione e tutto ciò che si può fare è eseguire alcuni test sull'hardware comune.

Ero annoiato alla riunione del dipartimento di oggi, quindi ho provato a mettere insieme un po 'di codice che crea contesti OpenGL e prova un po' di rendering. Ho provato il rendering con e senza trame, con e senza contesto OpenGL compatibile.

Si è scoperto che il limite è piuttosto alto per le schede GeForce (forse anche senza limiti). Per Quadro desktop, c'era un limite di 128 contesti che erano in grado di ridisegnare correttamente, il programma era in grado di creare 128 contesti in più senza errori, ma le finestre contenevano spazzatura.

E 'stato ancora più interessante su ATi Radeon 6950, lì il ridisegno si è fermato alla finestra # 105 e la creazione del contesto di rendering # 200 non è riuscita.

Se si desidera provare da soli, il programma può essere trovato qui: Max OpenGL Contexts test (c'è codice sorgente completo + file binari Win32).

Questo è il risultato. Un consiglio: evitare l'uso di più contesti laddove possibile. È possibile comprendere più contesti in un'applicazione in esecuzione su più monitor, ma le applicazioni su un singolo monitor devono ricorrere a un singolo contesto. Il cambio di contesto è lento. E non è tutto. Le applicazioni in cui le finestre OpenGL sono sovrapposte a un'altra finestra richiedono regioni di ritaglio hardware. C'è una regione di clipping hardware su GeForce, otto o più su Quadro (le applicazioni CAD usano spesso finestre e menu che si sovrappongono alla finestra OpenGL, in contrasto con i giochi). Nel caso in cui siano necessarie più regioni, il rendering ricade sul software - quindi ancora una volta - avere molte finestre OpenGL (contesti) non è una buona idea.

Answer 4

Se si verificano così tanti problemi per impostare OpenGL in un modo multi-thread over-the-top, si potrebbe anche trarre vantaggio da esso e prendere in considerazione il passaggio a Vulkan. Vedete, per impostazione, l'architettura OpenGL canalizza tutte le complesse operazioni di disegno con il contesto/thread separato in un unico thread di driver che poi ridistribuisce tutte le chiamate attraverso i thread di hardware virtuale che mappano su ciascun contesto. Il driver è in sostanza un enorme collo di bottiglia perché non è esso stesso threaded, nonostante qualsiasi seduta glewmx. Semplicemente non è progettato per gestire questo bene.

Detto questo, sono curioso di sapere se hai usato una versione precedente di Glew, o se fai tutta la gestione dell'estensione in un altro modo, dato che le ultime librerie di glew non supportano più mx. Un motivo in più per cambiare.