# Mesa 3D

Mesa, também chamado Mesa3D e The Mesa 3D Graphics Library, é um driver de dispositivo de código aberto e implementação de software do OpenGL, Vulkan e de outras especificações. Suas partes mais importantes perceptíveis ao usuário são os dois drivers gráficos principalmente desenvolvidos e financiados pela Intel e pela AMD, que estão usando essas implementações. O Nouveau, um projeto de tamanho menor com o objetivo de criar um driver gráfico para placas de vídeo GeForce, em contraste, é principalmente um esforço comunitário. O Mesa implementa uma API padronizada independente de fabricante, independente de linguagem de programação e multiplataforma (principalmente em distribuições BSD e distribuições Linux), fazendo a interface com diversos drivers de hardware gráfico específicos de cada fabricante.
Além de aplicativos 3D, como jogos, servidores gráficos modernos (Glamor, do X.org ou Weston, do Wayland) usam o OpenGL/EGL; portanto, todo o sistema gráfico tipicamente é executado usando o Mesa. Drivers de gráficos proprietários (e.g. Nvidia GeForce driver e AMD Catalyst para Radeon) substitui todo o Mesa, fornecendo sua própria implementação de uma API de gráficos, em vez de fornecer um driver que se comunica com o Mesa. Enquanto a Nvidia hoje promove seu driver proprietário para jogos, A AMD promove seus drivers do Mesa (radeon e radeonSI) em substituição ao depreciado AMD Catalyst (anteriormente chamado fglrx).
O Mesa é hospedado pelo freedesktop.org e foi iniciado em agosto de 1993 por Brian Paul, que ainda está ativo no projeto. O Mesa foi posteriormente amplamente adotado, e agora contém inúmeras contribuições de vários indivíduos e corporações em todo o mundo, incluindo os fabricantes de hardware gráfico do Khronos Group que administra a especificação OpenGL. Para o Linux, o desenvolvimento também foi parcialmente conduzido por financiamento coletivo.

## Visão geral
### Implementações das APIs de renderização

O Mesa é conhecido por hospedar as implementações de APIs gráficas. Historicamente, a API principal que o Mesa implementou é a OpenGL, juntamente com outras especificações relacionadas do Khronos Group (como o OpenVG, OpenGL ES ou recentemente a EGL). Mas o Mesa pode implementar outras APIs e, de fato, fez com a Glide (obsoleta) e o Direct3D 9 (desde julho de 2013.). O Mesa também não é específico para sistemas operacionais semelhantes ao Unix: no Windows, por exemplo, o Mesa fornece uma API OpenGL rodando em cima do DirectX.
O Mesa implementa uma camada de tradução entre uma API de gráficos, como OpenGL, e os drivers de hardware de gráficos no núcleo do sistema operacional. A versão suportada das diferentes APIs gráficas depende do driver, porque cada driver de hardware possui sua própria implementação (e, portanto, status). Isto é especialmente verdadeiro para os drivers "clássicos", enquanto os drivers do Gallium3D compartilham o código comum que tendem a homogeneizar as extensões e as versões suportadas.
Mesa mantém uma matriz de suporte com o status da atual conformidade ao OpenGL visualizado em mesamatrix.net. Mesa 10 está em conformidade com o OpenGL 3.3, para hardware de GPU Intel, AMD/ATI e Nvidia. O Mesa 11 foi anunciado com alguns drivers sendo compatíveis com o OpenGL 4.1.
Mesa 12 contém suporte a OpenGL 4.2 e 4.3 e Intel Vulkan 1.0.
Mesa 13 trouxe o suporte da Intel para o OpenGL 4.4 e 4.5 (todos os recursos suportados para Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), mas não o Khronos-Test para 4.5) e suporte experimental do AMD Vulkan 1.0 através do driver da comunidade, o RADV. OpenGL ES 3.2 é possível com o Intel Skylake (Gen9).
A versão estável atual é a 17.0 (baseada em contagem de ano novo). Os recursos prontos são o suporte ao OpenGL certificado v4.5, OpenGL 4.5 para o Intel Haswell, OpenGL 4.3 para NVidia Maxwell e Pascal (GM107+). Ganho de desempenho enorme foi medido com Maxwell 1 (GeForce GTX 750 Ti e outras com GM1xx). Placas Maxwell 2 (GeForce GTX 980 e outras com GM2xx) estão com clock abaixo do máximo devido à recusa da NVidia em liberar as especificações aos desenvolvedores.
A suíte de testes CTS Khronos para OpenGL 4.4, 4.5 e OpenGL ES 3.0+ está agora (2017-01-24) em código aberto e todos os testes para o Mesa v13 e v17 agora são possíveis sem custos.
Uma nova versão, 17.1.0, surgiu em 10 de maio de 2017 com algumas melhorias interessantes. OpenGL 4.2+ para Intel Ivy Bridge e OpenGL 3.3+ para o rasterizador Open SWR da Intel são dois dos destaques.
Note-se que, devido à natureza modularizada do OpenGL, o Mesa pode atualmente suportar extensões das versões mais recentes do OpenGL sem reivindicar o suporte total para tais versões. Por exemplo, em julho de 2016, o Mesa suportou não só o OpenGL ES 3.1, mas também todas as extensões do OpenGL ES 3.2, exceto cinco, bem como várias extensões que não fazem parte de nenhuma versão do OpenGL ou do OpenGL ES.
Uma questão aberta para o Mesa e o Linux é o grande alcance dinâmico (HDR). Muitos problemas e questões abertas estão sendo discutidos para elaborar uma implementação limpa e básica.
A versão 17.2 está disponível desde setembro de 2017 com suporte para alguns dos novos recursos do OpenGL 4.6 e melhorias de velocidade em 3D para Intel e AMD.
A versão 17.3 está pronta desde dezembro de 2017. Muitas melhorias em muitos drivers estão disponíveis. O OpenGL 4.6 está quase totalmente disponível (o Spir-V não está pronto). O driver Vulkan da AMD, o RADV, agora passa completamente no Khronos-Test.

#### Vulkan

O Khronos Group anunciou oficialmente a API Vulkan em março de 2015 e lançou oficialmente a Vulkan 1.0 em 16 de fevereiro de 2016. Vulkan quebra a compatibilidade com OpenGL e abandona completamente o conceito de estado de máquina monolítico. Os desenvolvedores do Gallium3D dizem que o Vulkan faz algo parecido ao Gallium3D 2.0 - o Gallium3D separa o código que implementa o estado de máquina do OpenGL do código que é específico ao hardware.
A Intel lançou sua implementação de um driver Vulkan para o seu hardware no dia em que a especificação foi oficialmente lançada, mas só foi adicionada à arvore de desenvolvimento principal em abril e assim tornou-se parte do Mesa 12.0, lançada em julho de 2016. Enquanto já o driver i965 não estava escrito de acordo com as especificações do Gallium3D, para o driver Vulkan ainda faz menos sentido executá-lo sobre o Gallium3D. Da mesma forma, não há nenhuma razão técnica para executá=lo sobre o NIR, mas, no entanto, os funcionários da Intel implementaram o driver Vulkan desse jeito.
É esperado que o driver Vulkan proprietário da AMD, que foi lançado em março, e foi anunciado para ser lançado como software livre e de código aberto no futuro e ser adicionado ao Mesa, também abandone o Gallium3D.
O RADV é um projeto livre em status beta para a AMD e está disponível desde a versão 13. A conformidade com Khronos-Test veio na versão 17.3.
A Nvidia lançou seu driver proprietário GeForce com o suporte ao Vulkan no dia do lançamento e a Imagination Technologies (PowerVR), a Qualcomm (Adreno) e a ARM (Mali) fizeram o mesmo ou pelo menos anunciaram drivers Vulkan proprietários para Android e outros sistemas operacionais. Mas quando e se as implementações de Vulkan livres e de código aberto adicionais para essas GPUs aparecerão, continua a ser visto.

### Implementações de APIs de aceleração de vídeo

Existem três maneiras possíveis de fazer os cálculos necessários para a codificação e decodificação de fluxos de vídeo:
* use uma implementação de software de um algoritmo de compressão ou descompressão de vídeo (comumente chamado de CODEC) e execute este software na CPU
* use uma implementação de software de um algoritmo de compressão ou descompressão de vídeo (comumente chamado de CODEC) e execute este software na GPU (o motor de renderização em 3D)
* use uma implementação de hardware completa (ou parcial) de um algoritmo de compressão ou descompressão de vídeo; tornou-se muito comum integrar tais ASICs no chip do GPU/CPU/APU/SoC e, portanto, estão abundantemente disponíveis; Por razões de marketing, as empresas estabeleceram marcas para os seus ASIC, como PureVideo (Nvidia), Unified Video Decoder (AMD), Video Coding Engine (AMD), Quick Sync Video (Intel), DaVinci (Texas Instruments), CedarX (Allwinner), Crystal HD (Broadcom); alguns ASICs estão disponíveis para licenciamento como núcleo de propriedade intelectual de semicondutores; geralmente versões diferentes implementam diferentes algoritmos de compressão de vídeo e/ou de descompressão de vídeo; o suporte para esses ASIC geralmente pertence ao driver do kernel, para inicializar o hardware e fazer coisas em baixo nível. O Mesa, que é executado no espaço do usuário, abriga as implementações de várias APIs para software, por exemplo: VLC media player, GStreamer, HandBrake, etc..., para acessar esses ASICs de forma conveniente:
* Video Acceleration API (VAAPI) – a API mais comum para Linux, usada pela AMD e Intel
* Video Decode and Presentation API for Unix (VDPAU) – usada pela Nvidia
* DirectX Video Acceleration (DXVA) – somente no Microsoft Windows
* OpenMAX IL – projetada pelo grupo Khronos para compressão de vídeo
* Distributed Codec Engine (DCE) – projetada por Texas Instruments
* X-Video Bitstream Acceleration (XvBA) – extensão para Xv - sucedida pela VAAPI
* X-Video Motion Compensation (XvMC) – extensão para Xv - sucedida pela VAAPI
Por exemplo, o Nouveau, que foi desenvolvido como parte do Mesa, mas também inclui um componente do kernel do Linux, que está sendo desenvolvido como parte do kernel do Linux, suporta os ASIC da marca PureVideo e fornece acesso a eles através da VDPAU e parcialmente através da XvMC.
O driver livre radeon suporta o Unified Video Decoder e o Video Coding Engine através da VDPAU e da OpenMAX.
Por favor, note que a V4L2 é uma interface de espaço de kernel para espaço de usuário para fluxos de bits de vídeo entregues por webcams ou sintonizadores de TV.

### Drivers de dispositivo

Os drivers de dispositivos livres e de código aberto disponíveis para chipsets gráficos são "gerenciados" pelo Mesa (porque a implementação de APIs livre e de código aberto existente é desenvolvida dentro do Mesa). Atualmente, existem dois frameworks para escrever drivers de gráficos: "clássico" e Gallium3D. Uma visão geral sobre alguns (mas não todos) dos drivers disponíveis no Mesa é dada em mesamatrix.net.
Existem drivers de dispositivo para as GPUs da AMD/ATI R100 ao R800, da Intel, e da Nvidia com aceleração 3D. Anteriormente, existiam drivers para a APU Cell do PlayStation 3 fabricado pela IBM/Toshiba/Sony, chipsets S3 Virge & Savage, chipsets da VIA, Matrox G200 & G400, e outros.
Os drivers livres e de código aberto competem com drivers proprietários de código fechado. Dependendo da disponibilidade da documentação do hardware e de mão de obra, os drivers livres e de código aberto ficam mais ou menos atrás em suporte à aceleração 3D de hardwares novos. Além disso, o desempenho de renderização em 3D geralmente foi significativamente mais lento com algumas exceções notáveis. Hoje, isso ainda é verdade para o Nouveau, driver aberto para a maioria das GPUs da NVIDIA, enquanto que nas GPUs Radeon da AMD, o driver aberto agora corresponde ou excede o desempenho do driver proprietário.

### Direct Rendering Infrastructure (DRI)

No momento em que as placas de vídeo 3D tornaram-se mais presentes em PCs, indivíduos parcialmente apoiados por algumas empresas começaram a trabalhar em adicionar mais suporte para renderização em 3D acelerada por hardware para o Mesa. O Direct Rendering Infrastructure (DRI) foi uma dessas abordagens para fazer a interface entre o Mesa, o OpenGL e outras bibliotecas da API de renderização 3D, e os drivers de dispositivo e o hardware. Depois de atingir um nível básico de usabilidade, o suporte ao DRI foi adicionado oficialmente ao Mesa. Isso ampliou significativamente a gama disponível de suporte de hardware possível ao usar a biblioteca Mesa.

### Renderizador de software

Renderização de software é o termo enganador, quando os shaders são executados na CPU ao invés de serem executados na GPU. O Mesa também contém uma implementação de renderização de software que permite que shaders sejam executados na CPU como um recurso alternativo quando nenhum acelerador de hardware de gráficos estiver presente, chamado swrast. O renderizador de software Gallium é conhecido como softpipe, ou quando é compilado com suporte ao LLVM, llvmpipe, que gera o código da CPU em tempo de execução. Desde o Mesa 10.x, o OpenGL 3.3+ é suportado no Softpipe (10.3) e no LLVMpipe (10.2). Atualmente, cerca de 80% dos recursos do OpenGL 4.x são implementados no Mesa 17.3 (veja Mesamatrix).
No Mesa 12.0, um novo rasterizador da Intel, o OpenSWR está disponível oferecendo grandes vantagens em clusters para manipular grandes conjuntos de dados. Ele está mais focado na visualização de engenharia do que nas imagens de jogos ou de artes e só funciona em processadores x86. Por outro lado, o OpenGL 3.1+ é agora suportado. O seu desempenho pode ser de 29 a 51 vezes superior em relação ao do LLVMPIPE em alguns exemplos. Para habilitá-lo, só uma mudança na variável de ambiente "GALLIUM_DRIVER="swr" é necessária. O OpenGL 3.3+ é suportado no OpenSWR desde o Mesa 17.1.

## História

O iniciador do projeto Brian Paul era um hobbyista gráfico. Ele pensou que seria divertido implementar uma biblioteca de gráficos 3D simples usando a API OpenGL, que ele poderia usar em vez do VOGL (very ordinary GL Like Library). Começando em 1993, ele passou dezoito meses de desenvolvimento em tempo parcial antes de lançar o software na Internet. O software foi bem recebido, e as pessoas começaram a contribuir para o seu desenvolvimento. No início, o Mesa renderizava todos os gráficos de computador em 3D na CPU. Apesar disso, a arquitetura interna do Mesa foi projetada para ser estendida para fazer a renderização em 3D acelerada pelo processador gráfico. Nesta primeira fase, a renderização foi feita indiretamente no servidor de exibição X, com alta sobrecarga e velocidade perceptível ficando abaixo da máxima teórica. A placa de vídeo Diamond Monster 3D, usando o chipset Voodoo Graphics, foi um dos primeiros dispositivos de hardware 3D suportados pelo Mesa.
O primeiro suporte verdadeiro ao hardware de gráficos foi adicionado ao Mesa em 1997, com base na API Glide para as novas placas de vídeo 3dfx Voodoo I/II e suas sucessoras. Um grande problema de usar a Glide como a camada de aceleração era o hábito da Glide de rodar só em tela cheia, que só era adequado para rodar jogos de computador. Além disso, o Glide bloqueava a memória da tela e, portanto, o servidor de exibição foi bloqueado para fazer outras tarefas da interface gráfica.