Cosa fa effettivamente LIBGL_ALWAYS_INDIRECT = 1?

KDE SC 4.5.0 ha alcuni problemi con alcune schede video tra cui la mia. In occasione del rilascio, Arch ha raccomandato diverse soluzioni alternative . Uno dei quali era

esporta "LIBGL_ALWAYS_INDIRECT = 1" prima di avviare KDE

Ho deciso che era il metodo più semplice e migliore. Ma non so cosa fa o come influisce sul mio sistema. È più lento di quello predefinito? dovrei ricordare di tenere d'occhio il problema e disabilitarlo in seguito una volta risolto?

Il rendering indiretto significa che il protocollo GLX verrà utilizzato per trasmettere i comandi OpenGL e X.org eseguirà il disegno reale.

Il rendering diretto significa che l'applicazione può accedere direttamente all'hardware senza prima comunicare con X.org tramite mesa.

Il rendering diretto è più veloce in quanto non richiede il cambio di contesto nel processo X.org.

Chiarimento: in entrambi i casi il rendering viene eseguito dalla GPU (o tecnicamente - può essere eseguito dalla GPU). Tuttavia, nel rendering indiretto il processo si presenta come:

1. Il programma chiama un comando (i)
2. I comandi sono / sono inviati a X.org dal protocollo GLX
3. X.org chiama hardware (cioè GPU) per disegnare

Nel rendering diretto

1. Il programma chiama un comando (i)
2. I comandi vengono / vengono inviati alla GPU

Si noti che, poiché OpenGL è stato progettato in modo tale da funzionare in rete, il rendering indiretto è più veloce, quindi l'implementazione dell'architettura sarebbe ingenua, ovvero consente di inviare una serie di comandi in una volta sola. Tuttavia, vi è un certo sovraccarico in termini di tempo della CPU impiegato per switch di contesto e protocollo di gestione.

Innanzitutto, LIBGL_ALWAYS_INDIRECTè un flag relativo all'implementazione OpenGL lato client Mesa 3D (libGL.so). Non funzionerà con i driver binari di altri fornitori (ad esempio NVIDIA).

In secondo luogo, per rispondere direttamente alla tua domanda, per ultimo ho guardato il codice Mesa la bandiera funziona in questo modo:

Prima del 2008, quando Mesa stava lavorando con un server X indiretto (ad esempio, hai ssh -Ximpostato o impostato esplicitamente il tuo display su un server non locale), l'elenco delle immagini GLX fornite dal server X remoto era disponibile per la tua applicazione GLX. L'applicazione chiama ad es. GlXChooseVisual () e Mesa troverebbe qualcosa di ragionevole da abbinare, e le successive glFoo()chiamate sarebbero inviate al server X remoto dove venivano eseguite da qualsiasi libGL a cui era collegato il server X remoto (probabilmente la tua GPU).

Verso la fine del 2008 Mesa è stata modificata in modo da voler utilizzare il suo software di rendering OpenGL ( driver Xlib ) per le connessioni X remote. (Alcune distribuzioni come SuSE hanno risolto questo problema in modo specifico per tornare al vecchio comportamento.) Ciò si avviava solo se il server X remoto offriva un visual GLX che corrispondeva esattamente a uno dei renderer software interni. (Altrimenti otterresti il ​​comune " Errore: impossibile ottenere un RGB, doppio buffer visivo ".) Se fosse trovato un simile oggetto visivo, Mesa eseguirà il rendering di tutti i glFoo()comandi con la CPU locale (all'applicazione) e invierà il risultato al server X remoto tramite immagini raster ( XPutImage()); Impostazione LIBGL_ALWAYS_INDIRECT=1(prima di Mesa 17.3 qualsiasi valore avrebbe funzionato, da allora è necessario utilizzare 1 o true) dice a Mesa di ignorare il normale rendering diretto o il renderer software interno e utilizzare il rendering indiretto come una volta.

La scelta del rendering indiretto o del rendering diretto del software influenzerà due cose:

Versione OpenGL

• Il rendering indiretto è generalmente limitato a OpenGL 1.4.
• Il rendering diretto del software supporterà qualsiasi supporto del rasterizzatore software Mesa, probabilmente OpenGL 2.1+

Prestazione

• Se l'applicazione è progettata per connessioni indirette (utilizza elenchi di visualizzazione, riduce al minimo le query di andata e ritorno), è possibile ottenere prestazioni ragionevoli.
• Se la tua applicazione fa qualcosa di stupido come glGetInteger()100 volte per frame, anche su una LAN veloce ciascuna di queste query occuperà facilmente 1ms, o 100ms in totale per frame, il che significa che non potresti mai ottenere più di 10 FPS nella tua applicazione.
• Quella stessa applicazione, se il carico di rendering non è troppo pesante, può funzionare molto bene con il rendering diretto del software, dal momento che tutte queste glGetInteger()chiamate ricevono risposta direttamente in questione di micro o nanosecondi.
• Se la tua applicazione crea un elenco di visualizzazione da un milione di vertici e quindi esegue molte rotazioni, il rendering indiretto con una GPU reale all'altra estremità fornirà prestazioni molto migliori.
• Un'applicazione può anche ricorrere a un percorso di codice diverso quando ha solo OpenGL 1.4 vs 2.x disponibile, che può anche influire sulle prestazioni.

Quindi, puoi vedere senza i dettagli esatti della tua applicazione e le caratteristiche della tua rete, è impossibile dire se il rendering diretto del software o il rendering indiretto è migliore per una determinata situazione.

Nel tuo caso sembra che tu stia eseguendo un'istanza kwin locale, quindi l'effetto di LIBGL_ALWAYS_INDIRECTforzare il rendering indiretto sul tuo server X locale. Apparentemente ciò cambia kwinil comportamento (solo OpenGL 1.4) o evita altri bug.

Sicuramente vuoi rimuovere questo flag quando viene risolto il problema sottostante.