OpenGL

OpenGL, contração de Open Graphics Library, é todo um universo circundante do mundo da computação gráfica. Pois é, não é a ideia rasa que você tem disso, leitor. Então você está convidado a prosseguir e desbravar.

OpenGL é uma interface de programação de aplicação (API) de renderização 3D acelerada por hardware mais usada e suportada desde 1992, a qual provém um amplo conjunto de funcionalidades, permitindo ao programador manipular gráficos e imagens utilizando todo o poder computacional das GPUs. OpenGL, por si, não é um software, mas meramente uma “especificação” desenvolvida e manutenida, como o Vulkan, pelo consórcio Khronos Group.

Em suma, OpenGL é, em si, um projeto descrevendo como um driver de vídeo deveria ser e como as interações com o mesmo deveriam ser realizadas, cabendo a cada um criar um produto OpenGL a partir deste projeto, daí temos os drivers de vídeo da AMD, Intel, NVidia, dentre outros nomes, para todas as plataformas e dispositivos.

História (breve)

OpenGL foi primeiramente criado como uma alternativa aberta e reproduzível ao IrisGL, o qual foi a API proprietária de gráficos nas estações de trabalho da Silicon Graphics. Embora OpenGL haja sido inicialmente similar em ampla percepção ao IrisGL, a falta de uma especificação formal e testes de conformidade fizeram do OpenGL inadequada para adoção massiva.

Mark Segal e Kurt Akeley compuseram a especificação 1.0 do OpenGL, a qual tentou formalizar a definição de uma API cruze-plataforma usável de gráficos e, fez viável a implementação e a manutenção terceirizadas não apenas pela SGI.

Uma notável omissão da versão 1.0 foi a falta dos objetos de textura. IrisGL havia definição e estágios de ligamento para toda sorte de objetos, incluindo materiais, luzes, texturas e ambientações. Estes objetos foram evitados em favor de alterações incrementais de estado com a ideia de que alterações coletivas poderiam ser encapsuladas em listas de exibição. Isto remanesceu na filosofia com exceção que objetos de textura sem distinção de estágio são uma parte-chave da API.

OpenGL atravessou um número de revisões as quais foram predominantemente adições incrementais onde extensões à API do núcleo foram gradualmente incorporadas ao corpo principal da API. Por exemplo, a versão 1.1 adicionou a extensão de ligação de textura à API do núcleo.

A versão 2.0 incorporou a adição significante da linguagem de shader, OpenGL Shading Language (GLSL), uma linguagem ao estilo C com a qual os estágios de transformação e sombreamento de pixel da linha de produção de gráficos podem ser programados.

A versão 3.0 adicionou o conceito de depreciação: fazendo certos recursos como sujeitos a remoção em versões futuras. Na versão 3.1, mais recursos depreciados foram removidos. E, na versão 3.2, foi criada a noção de contextos de perfil de núcleo e compatibilidade.

OpenGL tem uma história triste envolvendo sabotagens por parte da Microsoft em favor do Direct3D, sua própria tecnologia equivalente. A Microsoft atrasou o progresso e o desenvolvimento da história de gráficos computacionais, e o produto de seus malfeitios são irreparáveis. Notoriamente podemos ver a dificuldade de usar outros sistemas operacionais devido a dependência exclusiva do Direct3D em praticamente todos os games. Nunca esqueça disso: a Microsoft atrasou a humanidade e deve ser responsabilizada até o seu último dia.

Outro grande problemas na história do OpenGL foram os constantes desentendimentos dos mantenedores, retardando a normalização de novas tecnologias, deixando o OpenGL sempre em desvantagem ao Direct3D. De fato, apenas na versão 3.2, OpenGL alcançou uma versão decente, mas já estamos falando de 2007, quando Direct3D já havia se enraizado no mercado.

Conceito

Você, leitor, provavelmente tem uma noção trivial de comparar OpenGL ao Direct3D (não confunda com DirectX), ou considerá-lo como mais um middleware de gráficos tal como abstrações de renderizadores da Unreal Engine, etc, confere? Bem… não é assim “tão simples”.

Apesar de não ser tão simples, a força-tarefa de conscientização da SIGMA tentará ser breve, já que brasileiro tem repúdio a leitura; grrr. Vamos lá.

OpenGL, em si, ou melhor, a “especificação”, especifica — óbvio — quais e como deveriam ser os resultados e saídas de cada função e funcionalidade, e por vezes como deveriam desempenhar sua tarefa. Então cabe aos desenvolvedores que implementam esta especificação chegar com uma solução de como cada função ou funcionalidade deveria operar.

Desde que a especificação do OpenGL não oferece detalhes, suas versões atuais desenvolvidas estão habilitadas a apresentarem diferentes implementações, conforme seus resultados consentem com a especificação (e sejam as mesmas para os usuários).

Basicamente, é como uma tomada e o plugue. Se você quiser que um equipamento eletrônico funcione na rede elétrica de qualquer lugar, você deveria normatizar o plugue para àquela norma de tomada.

OpenGL é também um nome associado ao driver de aceleração de hardware, o “software real” de cada VGA. Ao invés do programador lidar diretamente com as gambiarras da tríplice RGB — AMD, Intel, e NVidia — o programador segue a especificação OpenGL e estes fabricantes oferecem sua “implementação” do OpenGL, isto é, o driver real de hardware.

As pessoas desenvolvendo as atuais bibliotecas OpenGL são normalmente os fabricantes de hardware de vídeo, a destacar a tríplice RGB: AMD, Intel, e NVidia. Cada hardware acelerador de gráficos que você compra suporta versões específicas do OpenGL, as quais são versões desenvolvidas especificamente para aquele hardware. Por isso um driver não opera propriamente num outro hardware diferente, ainda que seja duma mesma série ou família de produtos.

OpenGL é também um nome associado a toda ABI que oferece funcionalidade a esta especificação. Em um sistema da Apple, a biblioteca OpenGL é manutenida pela Apple mesmo, e sob Linux, existe uma combinação de versões de suplentes de gráfico e adaptações de voluntários destas bibliotecas.

Na indústria da computação gráfica em geral, principalmente do CAD, é comum ver menções sobre OpenGL, principalmente porque, normalmente, todo desenvolvedor tenta se aproximar ao máximo da especificação do OpenGL ao fazer seu middleware para games, editores tridimensionais, ilustradores assistidos, etc, para tentar uma compatibilidade maior com o mercado, mesmo que OpenGL não tenha relação nenhuma com aquilo. Matrizes, vetores, o esquema de coordenadas em geral, são grandes destaques.

Imagens

Não há o que mostrar exatamente, uma vez que OpenGL, Vulkan, etc, não passam de “faces diferentes da mesma moeda”, isto é, toda a capacidade dessas tecnologias não é realmente “delas”, mas do hardware de vídeo. Tudo que uma pode fazer a outra também pode, isto porque é uma capacidade da VGA, não da API.

Vide o exemplo a seguir. Aqui vemos o OpenGL, uma tecnologia que, apesar de ser manutenida até hoje, foi criada na década de 1980, ladeada ao que temos de mais novo e poderoso, a tecnologia Vulkan, sua irmã sucessora. Visualmente há nada a destacar. Os diferenciais aqui são técnicos.

Comparativo técnico com Doom III entre Vulkan e OpenGL.
Teste de renderização gráfica de conceito de deferred rendering

Postagens relacionadas

OpenAL

OpenAL, contração de Open Audio Library, é uma interface cruze-plataforma de programação para hardware de aceleração de áudio. Esta API é designada à eficiente renderização em…

Vulkan

Vulkan, incialmente apresentada como OpenGL Next, é uma API de computação e de realização de gráficos 2D e 3D, multiplataforma, de baixa sobrecarga, destinada a uso…

Comentários