O que LIBGL_ALWAYS_INDIRECT = 1 realmente faz?

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

exporte "LIBGL_ALWAYS_INDIRECT = 1" antes de iniciar o KDE

Decidi que era o melhor e mais fácil método. Mas não sei o que faz ou como afeta o meu sistema. É mais lento que o padrão? devo me lembrar de ficar de olho no problema e desabilitá-lo mais tarde, depois de corrigido?

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 se comunicar primeiro com o X.org via mesa.

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

Esclarecimento: Nos dois 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 (s) comando (s)
2. Os comandos são / são enviados para o X.org pelo protocolo GLX
3. O X.org chama o hardware (ou seja, GPU) para desenhar

Na renderização direta

1. O programa chama um (s) comando (s)
2. Os comandos são / são enviados à GPU

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

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

Segundo, para responder sua pergunta diretamente, por último, olhei para o código Mesa e a bandeira funciona assim:

Antes de 2008, quando o Mesa estava trabalhando com um servidor X indireto (por exemplo, você ssh -Xconfigurou ou definiu explicitamente sua exibição para um servidor não local), a lista de recursos visuais GLX fornecidos pelo servidor X remoto fica disponível para o seu aplicativo GLX. As chamadas do aplicativo, por exemplo, glXChooseVisual () e Mesa, encontrariam algo razoável para corresponder e as glFoo()chamadas subsequentes seriam enviadas para o servidor X remoto, onde eram executadas por qualquer libGL que o servidor X remoto estivesse conectado (provavelmente sua GPU).

Por volta do final de 2008, o Mesa foi alterado para permitir o uso de seu renderizador OpenGL de software interno ( driver Xlib ) para conexões X remotas. (Algumas distribuições como o SuSE corrigiram isso especificamente para voltar ao comportamento antigo.) Isso só ocorreria se o servidor X remoto oferecesse um visual GLX que correspondesse exatamente a um processador de software interno. (Caso contrário, você obteria o comum, " Erro: não foi possível obter um visual RGB com buffer duplo ".) Se esse visual fosse encontrado, o Mesa renderizaria todos os glFoo()comandos com a CPU local (para o aplicativo) e pressione o botão resultado para o servidor X remoto através de imagens raster ( XPutImage()); Configuração LIBGL_ALWAYS_INDIRECT=1(antes do Mesa 17.3 qualquer valor funcionaria, desde então você deve usar 1 ou true) diz ao Mesa para ignorar a renderização direta normal ou o renderizador de software interno e usar a renderização indireta como costumava fazer.

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

Versão do OpenGL

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

atuação

• 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 ocupará facilmente 1 ms ou 100 ms no total por quadro, o que significa que você nunca poderá obter mais de 10 FPS no seu aplicativo.
• 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 essas glGetInteger()chamadas são atendidas diretamente em questão de micro ou nanossegundos.
• Se o seu aplicativo criar uma lista de exibição de um milhão de vértices e, em seguida, executar muitas rotações, a renderização indireta com uma GPU real na outra extremidade fornecerá um desempenho muito melhor.
• Um aplicativo também pode retornar a um caminho de código diferente quando só tiver 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 da sua aplicação e das características da sua rede, é impossível dizer se a renderização direta de software ou indireta é melhor para qualquer situação.

No seu caso, parece que você está executando uma instância local do kwin, portanto o efeito de LIBGL_ALWAYS_INDIRECTé forçar a renderização indireta para o servidor X local. Aparentemente, isso altera kwino comportamento (apenas OpenGL 1.4) ou evita outros erros.

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