Exceto o OpenGL, eu nunca usei essas bibliotecas, mas vou tentar adivinhar, lendo páginas da Wikipedia, como você fez.
Você parece certo sobre Mesa. Aqui estão as informações adicionais que temos:
"O sistema X window é um sistema de software e protocolo de rede que fornece uma GUI básica para computadores em rede. Cria uma camada de abstração de hardware".
"O GLX permite que programas que desejam usar o OpenGL façam isso em uma janela fornecida pelo Sistema X Window. O
GLX consiste em três partes:
- Uma API que fornece funções OpenGL.
- Uma extensão do protocolo X, que permite ao cliente enviar 3D comandos de renderização - Uma extensão do servidor X que recebe os comandos de renderização do cliente e os passa para a biblioteca OpenGL instalada.
Se o cliente e o servidor estiverem em execução no mesmo computador e uma placa gráfica 3D acelerada estiver disponível, os dois primeiros componentes poderão contornado pelo DRI. O programa cliente pode acessar diretamente o hardware gráfico ".
"A Direct Rendering Infrastructure (DRI) é uma interface usada no Sistema X Window para permitir que aplicativos do usuário acessem o hardware de vídeo sem exigir que os dados sejam transmitidos pelo servidor X".
"O Open Inventor é uma API gráfica 3D C ++ projetada para fornecer uma camada mais alta de programação para o OpenGL"
Para simplificar, vamos imaginar um fluxo simplificado de dados (e comandos) que acontece nas entradas e saídas de cada uma dessas APIs. No início, temos o seu aplicativo (código compilado), que você executa no seu computador. No final, temos imagens exibidas na tela.
Existem vários casos que restringirei às respostas a estas perguntas: - o
seu computador possui uma placa gráfica (GPU) ou apenas uma CPU para processar funções gráficas?
- seu aplicativo está incorporado em uma janela do sistema x-window?
-se você usa o sistema x window, o "servidor x" está sendo executado no seu computador ou em outro computador na rede?
Suponho que você tenha os drivers para sua GPU, se você tiver um, e que você tenha o Mesa para a renderização do software).
Primeiro cenário: você executa um aplicativo gráfico escrito com o OpenInventor, sem usar o Sistema X Window, e não possui uma placa gráfica. O fluxo do programa seria bastante semelhante a:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
O que acontece aqui é chamado de "renderização de software": o comando graphics não é tratado por nenhum hardware gráfico, mas pela CPU usual, o processador que geralmente executa o software.
Segundo cenário: agora imagine que, com as mesmas condições acima, você tenha uma placa gráfica. O fluxo ficaria mais ou menos assim:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
O que acontece agora é chamado de "aceleração de hardware", geralmente mais rápido que o primeiro cenário.
Terceiro cenário: agora vamos apresentar o fluxo do X Window System, ou pelo menos como eu penso, com base nas poucas linhas da Wikipedia que li.
Vamos esquecer o hardware gráfico e a API por um tempo. O fluxo deve se parecer com:
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
Observe que, ao usar o X Window System, a tela e o computador em que você executa o aplicativo podem não estar "diretamente" conectados, mas podem estar conectados através de uma rede.
Quarto cenário: suponha que você queira adicionar renderizações gráficas 3D sofisticadas ao seu aplicativo X Client do exemplo anterior. Parece-me que o X Window System não é capaz de fazer isso originalmente, ou pelo menos seria necessário muito código complicado para executar o equivalente a uma função da API do OpenGL.
Felizmente, você pode usar o GLX para adicionar suporte aos comandos do OpenGL no sistema. Agora você tem:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
Agora você pode reconectar a última seta àquela após "OpenGL" no primeiro cenário: você pode obter imagens em 3D na tela!
Finalmente, sobre o que eu acho que entende do DRI:
parece permitir que o Mesa tenha acesso à GPU, de modo que modificaria o fluxo do nosso primeiro cenário para:
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
E também parece causar um curto-circuito no fluxo ao usar o GLX, considerando a condição de que o servidor e o cliente estejam no mesmo computador e que você tenha uma GPU. Nesse caso, o gráfico do nosso quarto cenário se tornaria simplesmente:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
É isso aí !
Agora, lembre-se de que eu não sou especialista em ambientes Unix, portanto, meu melhor conselho é estudar a documentação de cada uma dessas APIs para saber exatamente o que elas podem fazer.
Combinar o gráfico anterior em um único pode facilitar a compreensão das coisas. Eu deixei isso como um exercício para você!
OpenGL é independente de plataforma; isso significa que a API OpenGL é independente da plataforma.
Os estados e buffers do OpenGL são coletados por um objeto abstrato, geralmente chamado de contexto.
A plataforma de hospedagem é responsável por fornecer alguma API para criar o contexto OpenGL para a plataforma subjacente. No Windows, existem as rotinas wgl * (Windows para GL), no Unix, existem rotinas glX * (GL for X).
Na verdade, o GLX nada mais é do que uma API que permite que o aplicativo crie um contexto OpenGL, a fim de usar a API OpenGL.
As operações WGL / GLX comuns são a criação de uma janela, a criação de um buffer fora da tela, tornar o contexto OpenGL atual em um encadeamento, trocar buffers de desenho ...
O DRI é uma camada do kernel que permite a comunicação direta com a placa gráfica, ignorando o XServer, acelerando o aplicativo usando rotinas OpenGL.
fonte
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
A Direct Rendering Infrastructure, também conhecida como DRI, é uma estrutura para permitir o acesso direto ao hardware gráfico no Sistema X Window de maneira segura e eficiente. Ele inclui alterações no servidor X, em várias bibliotecas clientes e no kernel (DRM, Direct Rendering Manager). O uso mais importante para o DRI é criar implementações rápidas do OpenGL, fornecendo aceleração de hardware para o Mesa. Vários drivers acelerados em 3D foram gravados na especificação DRI, incluindo drivers para chipsets produzidos pela 3DFX, AMD (anteriormente ATI), Intel e Matrox.
fonte
Simplificando, OpenGL é o tipo e a especificação da biblioteca de gráficos. Mesa é uma implementação básica. DRI é um sistema de interface de hardware.
Mesa se refere basicamente a toda a estrutura. No entanto, presumo que você esteja falando do driver de hardware Mesa.
DRI é basicamente a interface do kernel para lidar com o hardware. Tecnicamente, poderia ser usado para outras coisas, mas foi feito para o Mesa e é usado principalmente para o Mesa.
GLX é como tudo faz interface com o X !!
Para entender o que cada parte é, você precisa saber como ela se encaixa.
Um programa foi projetado para interagir com qualquer biblioteca openGL.
O GLX é um meio de fazer interface com o OpenGL com ou através do X11. Dependendo se você possui uma interface "Direta" ou uma interface "Indireta", depende se o seu programa se preocupará com isso.
libGL é praticamente a interface para eles. Geralmente é fornecido pelo Mesa se você estiver usando um driver do Mesa.
Em uma configuração indireta, é o seguinte: Application Framework (por exemplo, aplicativo escrito, mecanismo ou API de abstração) | LibGL Mesa Driver | DRI Hardware
Nesta configuração, o GLX é usado apenas no lado para lidar com a interface entre o uso do GL do seu programa e outros programas. Além das chamadas específicas do GLX, costumava fazer coisas que exigem comunicação da pilha X11 e de seus programas de suporte (como o Windows Managers). O GLX é praticamente intocado. neste arranjo.
Além disso, a passagem de comando e a memória compartilhada podem ser usadas para otimizar ainda mais as camadas neste sistema. Isso tudo reduz latências e melhora a velocidade de acesso ao hardware. Isto é o que você normalmente quer.
Para um indireto, é o Your Application Framework | LibGL (lado do usuário) | LibGLX LibGL (lado X11) | Driver de Hardware para Mesa | DRI Hardware
A vantagem disso é que você não precisa de um buffer de memória compartilhada direta com o hardware para usar esta configuração. (Permitindo clientes de rede, além de mais robustez e uma configuração mais segura.)
Essa configuração pode funcionar em várias VMs que compartilham uma única placa de vídeo ou até mesmo acessam uma rede por causa disso. Algumas formas de memória compartilhada ou memória "clonada" compartilhada virtual podem ser usadas devido a extensões mais recentes, mas não é o acesso direto à memória de vídeo encontrado no modo de renderização direta.
A desvantagem é que o uso de pipes ou soquetes de rede para fazer interface com o X11 pode ser lento, pelo menos introduzindo latências em programas bem otimizados e, na pior das hipóteses, diminuindo drasticamente as taxas de quadros nos menos otimizados.
Esse é o tipo de configuração que é melhor para clientes em rede, configurações que exigem segurança mais robusta e configurações em que vários sistemas operacionais precisam compartilhar hardware executando a mesma pilha GL. Está longe de ser o ideal, mas oferece algum grau de aceleração de hardware.
fonte