it-swarm-pt.com

O que LIBGL_ALWAYS_INDIRECT = 1 realmente faz?

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

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 isso 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?

23
xenoterracide

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

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.

16
Maciej Piechotka

Primeiro, LIBGL_ALWAYS_INDIRECT É um sinalizador relacionado à implementação do OpenGL no lado cliente do Mesa 3D (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ê definiu ssh -X Ou configurou 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 seu aplicativo GLX. O aplicativo chama, por exemplo, O glXChooseVisual () e o Mesa encontrariam algo razoável para corresponder e as chamadas subsequentes glFoo() 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 poder usar seu processador interno OpenGL ( driver Xlib ) para conexões remotas do X. (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 foi encontrado o Mesa renderizaria todos os comandos glFoo() com a CPU local (para o aplicativo) e enviaria o resultado ao servidor X remoto por meio de imagens raster (XPutImage()); Definindo 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 em sua aplicação.
  • O mesmo aplicativo, se a carga de renderização não for muito pesada, pode ter um desempenho muito bom com a renderização direta de software, pois todas essas chamadas glGetInteger() 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, então o efeito de LIBGL_ALWAYS_INDIRECT É forçar a renderização indireta para o servidor X local. Aparentemente, isso 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.

14
Nathan Kidd