O que LIBGL_ALWAYS_INDIRECT = 1 realmente faz?

Question

O KDE SC 4.5.0 tem alguns problemas com algumas placas de vídeo, incluindo a minha. Após o lançamento, Arch recomendou várias soluções alternativas . Um dos quais foi

export "LIBGL_ALWAYS_INDIRECT=1" before starting KDE

Eu decidi que era o método mais fácil e melhor. Mas eu não sei o que isso faz ou como isso afeta meu sistema. É mais lento que o padrão? Devo lembrar de ficar de olho no problema e desativá-lo mais tarde, uma vez que foi corrigido?

    

Answer 1

A renderização indireta significa que o protocolo GLX será usado para transmitir comandos OpenGL e o X.org fará o desenho real.

A renderização direta significa que o aplicativo pode acessar o hardware diretamente sem comunicação com o X.org primeiro via mesa.

A renderização direta é mais rápida, pois não requer mudança de contexto no processo do X.org.

Esclarecimento: Em ambos os casos, a renderização é feita pela GPU (ou tecnicamente - pode ser feita pela GPU). No entanto, na renderização indireta, o processo se parece com:

1. O programa chama um comando (s)
2. Comandos são enviados para o X.org pelo protocolo GLX
3. O X.org chama hardware (isto é, GPU) para desenhar

Na renderização direta

1. O programa chama um comando (s)
2. Comando (s) é / são enviado para GPU

Por favor, note que como o OpenGL foi projetado de tal forma que pode operar através da rede, a renderização indireta é mais rápida do que seria a implementação ingênua da arquitetura, ou seja, permite enviar um buch de comandos de uma só vez. No entanto, existe alguma sobrecarga em termos de tempo de CPU gasto para comutadores de contexto e manipulação de protocolo.

    

Answer 2

Primeiro, LIBGL_ALWAYS_INDIRECT é um sinalizador relacionado à implementação do OpenGL no lado do cliente do Mesa 3D (libGL.so). Não funcionará com drivers binários de outros fornecedores (por exemplo, NVIDIA).

Em segundo lugar, para responder à sua pergunta diretamente, pela última vez eu olhei para o código da Mesa que a bandeira funciona assim:

Antes de 2008, quando a Mesa estava trabalhando com um servidor X indireto (por exemplo, você usou ssh -X ou definiu explicitamente sua exibição como um servidor não local), disponibilizaria a lista de visuais GLX fornecidos pelo servidor X remoto para sua aplicação GLX. O aplicativo chama, e. glXChooseVisual () e Mesa encontrariam algo razoável para combinar, e as chamadas glFoo() subseqüentes seriam enviadas para o servidor X remoto onde elas eram executadas por qualquer libGL que o servidor X remoto estivesse conectado (provavelmente a sua GPU).

Por volta do final de 2008, o Mesa foi alterado para que quisesse usar seu renderizador interno de software OpenGL ( driver Xlib ) para conexões remotas do X. (Algumas distribuições como a SuSE corrigiram isso especificamente para voltar ao antigo comportamento.) Isso só ocorreria se o servidor X remoto oferecesse um visual GLX que correspondesse exatamente ao renderizador de software interno. (Caso contrário, você obteria o comum ", Erro: não foi possível obter um RGB, Double-buffered visual ".) Se tal visual fosse encontrado, o Mesa renderizaria todos os comandos glFoo() com o CPU local (para aplicação), e empurre o resultado para o servidor X remoto através de imagens rasterizadas ( XPutImage() ); Configurar LIBGL_ALWAYS_INDIRECT=y (ou, incidentalmente, LIBGL_ALWAYS_INDIRECT=n tem o mesmo efeito, o código apenas verifica se env env está definido) diz à Mesa para ignorar a renderização direta normal ou o renderizador de software interno e usar renderização indireta como costumava. / p>

A escolha de renderização indireta ou renderização direta de software afetará duas coisas:

Versão OpenGL

• A renderização indireta é geralmente restrita ao OpenGL 1.4.
• A renderização direta de software suportará tudo o que o rasterizador de software da Mesa suportar, provavelmente o OpenGL 2.1 +

Desempenho

• Se seu aplicativo for projetado para conexões indiretas (ele usa listas de exibição, minimiza consultas de ida e volta), você pode obter um desempenho razoável.
• Se o seu aplicativo fizer algo estúpido como glGetInteger() 100 vezes por quadro, mesmo em uma LAN rápida, cada uma dessas consultas consumirá 1 ms ou 100 ms por quadro, ou seja, você nunca conseguirá mais de 10 FPS em seu aplicação.
• Esse mesmo aplicativo, se a carga de renderização não for muito pesada, pode funcionar muito bem com a renderização direta de software, pois todas as chamadas glGetInteger() são respondidas diretamente em uma questão de micro ou nanossegundos.
• Se o seu aplicativo criar uma lista de visualização de milhões de vértices e, em seguida, fizer muita rotação, a renderização indireta com uma GPU real na outra extremidade proporcionará um desempenho muito melhor.
• Um aplicativo também pode retornar a um caminho de código diferente quando tiver apenas o OpenGL 1.4 vs 2.x disponível, o que também pode afetar o desempenho.

Assim, você pode ver sem os detalhes exatos de sua aplicação e suas características de rede, é impossível dizer se a renderização direta de software ou renderização indireta é melhor para qualquer situação.

No seu caso, parece que você está executando uma instância kwin local, então o efeito de LIBGL_ALWAYS_INDIRECT é forçar a renderização indireta para o seu servidor X local. Isso aparentemente altera o comportamento de kwin (apenas OpenGL 1.4) ou evita algum outro bug.

Definitivamente, você deseja remover esse sinalizador quando o problema subjacente for corrigido.