Comparação de OpenGL e Direct3D - Comparison of OpenGL and Direct3D
Direct3D e OpenGL são interfaces de programação de aplicativos (APIs) concorrentes que podem ser usadas em aplicativos para renderizar gráficos de computador 2D e 3D . A partir de 2005, as unidades de processamento gráfico (GPUs) quase sempre implementam uma versão de ambas as APIs. Os exemplos incluem: DirectX 9 e OpenGL 2 por volta de 2004; DirectX 10 e OpenGL 3 por volta de 2008; e mais recentemente, DirectX 11 e OpenGL 4 por volta de 2011. GPUs que oferecem suporte a versões mais recentes dos padrões são compatíveis com versões anteriores de aplicativos que usam os padrões mais antigos; por exemplo, pode-se executar jogos DirectX 9 mais antigos em uma GPU certificada para DirectX 11 mais recente.
Disponibilidade
O desenvolvimento de aplicativos Direct3D é direcionado à plataforma Microsoft Windows .
A API OpenGL é um padrão aberto, o que significa que vários fabricantes de hardware e desenvolvedores de sistema operacional podem criar livremente uma implementação OpenGL como parte de seu sistema. As implementações OpenGL existem para uma ampla variedade de plataformas. Mais notavelmente, OpenGL é a API gráfica dominante dos sistemas de computador do tipo Unix.
Da perspectiva de um desenvolvedor de aplicativos, Direct3D e OpenGL são igualmente abertos; documentação completa e ferramentas de desenvolvimento necessárias estão disponíveis sem restrições.
| API | Suporte para desktop | Suporte de sistema integrado | Licença |
|---|---|---|---|
| Direct3D | Microsoft Windows , Xbox | Windows Embedded , Windows CE (por meio do Direct3D Mobile ) | Proprietário |
| OpenGL | Plataforma cruzada | Plataforma cruzada por meio de OpenGL ES | Padrão aberto, alguns recursos patenteados |
Em mais detalhes, as duas APIs de computação gráfica são as seguintes:
- Direct3D é uma API proprietária da Microsoft que fornece funções para renderizar gráficos bidimensionais (2D) e tridimensionais (3D) e usa aceleração de hardware, se disponível na placa gráfica. Ele foi projetado pela Microsoft Corporation para uso na plataforma Windows .
- OpenGL é uma API de padrão aberto que fornece muitas funções para renderizar gráficos 2D e 3D e está disponível na maioria dos sistemas operacionais modernos , incluindo, mas não se limitando a Windows , macOS e Linux .
Observe que muitas extensões e métodos OpenGL essenciais , embora documentados, também são patenteados, impondo sérios problemas legais para implementá-los (consulte os problemas com Mesa ).
OpenGL e Direct3D são implementados no driver do dispositivo de vídeo . Uma diferença significativa, entretanto, é que o Direct3D implementa a API em um runtime comum (fornecido pela Microsoft), que por sua vez se comunica com uma interface de driver de dispositivo de baixo nível (DDI). Com o OpenGL, cada fornecedor implementa a API completa no driver. Isso significa que algumas funções da API podem ter um comportamento ligeiramente diferente de um fornecedor para o outro. Os compiladores de sombreador GLSL de diferentes fornecedores também mostram um comportamento ligeiramente diferente. O seguinte compara as duas APIs, estruturadas em torno de várias considerações principalmente relevantes para o desenvolvimento de jogos.
Portabilidade
O Direct3D proprietária é implementado oficialmente apenas em família Microsoft Windows de sistemas operacionais, incluindo as versões embutidas utilizadas no Xbox família de consolas de jogos de vídeo e Sega 's Dreamcast . Várias reimplementações funcionais da API Direct3D foram feitas por terceiros, como Wine , um projeto para portar APIs Windows comuns para sistemas operacionais semelhantes ao Unix , e Cedega , um fork proprietário do Wine. No entanto, esse processo é progressivamente impedido devido à interdependência do DirectX com muitos outros componentes proprietários do Windows e porque a natureza proprietária do Direct3D requer o difícil processo de engenharia reversa .
OpenGL tem implementações disponíveis em muitas plataformas, incluindo Microsoft Windows, sistemas baseados em Unix , como Mac OS X , Linux . A Nintendo e a Sony desenvolveram suas próprias bibliotecas que são semelhantes, mas não idênticas ao OpenGL. Um subconjunto de OpenGL foi escolhido como a biblioteca gráfica principal para Android , BlackBerry , iOS e Symbian no formato OpenGL ES .
O driver OpenGL da Microsoft fornece aceleração de hardware no Windows Vista; o suporte foi abandonado no Windows XP, logo após eles falharem em fornecer suporte de baixo nível da API gráfica Fahrenheit para uma fusão OpenGL-Direct3D no final dos anos 1990. A aceleração de hardware OpenGL no Windows é alcançada pelos usuários primeiro instalando drivers de cliente instaláveis (ICDs) desenvolvidos por fabricantes de GPU . Esses ICDs são, em praticamente todos os casos, incluídos no pacote de download de driver padrão do fornecedor de hardware (IHV), portanto, a instalação de drivers gráficos recentes é suficiente para fornecer suporte OpenGL de hardware.
Mais recentemente, o projeto Quase Native Graphics Layer Engine ( ANGLE ) do Google fornece um meio de converter chamadas de aplicativos OpenGL ES 2.0 para DirectX 9 . Isso é feito para que o WebGL (uma variante de subconjunto do OpenGL para a web) possa ser executado no tempo de execução comum do Direct3D, o que significa que haverá menos variação entre os fornecedores.
Fácil de usar
Direct3D
A primeira versão do Direct3D em 1996 gerou muitas críticas porque até mesmo operações simples, como mudanças de estado, exigiam a criação e o envio de objetos chamados de buffers de execução . Em contraste, no OpenGL a maioria das mudanças de estado pode ser realizada com uma chamada de função. O modelo Direct3D frustrou muitos programadores. Uma reclamação muito famosa foi feita pelo desenvolvedor de jogos John D. Carmack em seu .planarquivo, no qual ele instava a Microsoft a abandonar o Direct3D em favor do OpenGL. Carmack explicou, "OpenGL é fácil de usar e divertido de experimentar. D3D não é. ... Muitas coisas que são uma única linha de código GL requerem meia página de código D3D - para alocar uma estrutura, definir um tamanho, preencher algo em, chame uma rotina COM e extraia o resultado. " Chris Hecker fez uma solicitação semelhante em uma "Carta Aberta à Microsoft" na edição de abril-maio de 1997 da Game Developer Magazine.
A versão 5 (a segunda versão, nomeada para refletir seu lançamento como parte do DirectX 5) substituiu os buffers de execução pela nova API DrawPrimitive, mas ainda era considerada complicada. A "Open Letter to Microsoft" de Chris Hecker referiu-se ao DrawPrimitive como "um clone imaturo e mal projetado do OpenGL que está perdendo algumas das decisões arquitetônicas que tornam o OpenGL rápido".
Apesar da polêmica, a Microsoft continuou a desenvolver a API. Um histórico detalhado de lançamentos e recursos adicionados é fornecido nas páginas da web do Microsoft Direct3D.
Alguns críticos anteriores do Direct3D reconhecem que agora o Direct3D é tão bom, senão melhor, que o OpenGL em habilidades e facilidade de uso. Em janeiro de 2007, John Carmack disse que "... DX9 é realmente um bom nível de API . Mesmo com o lado Direct3D das coisas, onde eu sei que tenho uma longa história de pessoas que pensam que sou antagônico a ele. A Microsoft fez uma grande , muito bom trabalho em desenvolvê-lo de forma sensata a cada etapa - eles não estão preocupados em quebrar a compatibilidade com versões anteriores - e é uma API bem limpa. Gosto especialmente do trabalho que estou fazendo no 360, e é provavelmente a melhor API gráfica como longe de ser uma coisa sensatamente projetada com a qual eu trabalhei. "
Alguns recursos de design do Direct3D permaneceram inalterados desde a versão um, principalmente sua dependência do Component Object Model (COM) da Microsoft . Uma vantagem de usar COM é que a API pode ser usada em qualquer linguagem compatível com COM, notavelmente Object Pascal ( Delphi ) e Microsoft Visual C ++ , C # e Visual Basic .NET .
OpenGL
OpenGL é uma especificação implementada na linguagem de programação C , embora possa ser usada em outras linguagens. Baseia-se no conceito de máquina de estado . Como uma API, o OpenGL não depende de nenhum recurso de linguagem de programação e pode ser chamado de quase qualquer linguagem com as ligações adequadas. Essas ligações existem para a maioria das linguagens de programação atuais.
Comparação
Em geral, o Direct3D é projetado para virtualizar interfaces de hardware 3D. O Direct3D libera o programador do jogo de acomodar o hardware gráfico. OpenGL, por outro lado, é projetado para ser um sistema de renderização acelerado por hardware 3D que pode ser emulado em software. Essas duas APIs são fundamentalmente projetadas sob dois modos distintos de pensamento.
Como tal, existem diferenças funcionais em como as duas APIs funcionam. Uma diferença funcional entre as APIs está em como elas gerenciam os recursos de hardware. O Direct3D espera que o aplicativo faça isso, o OpenGL faz com que a implementação faça isso. Essa compensação para OpenGL diminui a dificuldade de desenvolvimento para a API, enquanto, ao mesmo tempo, aumenta a complexidade da criação de uma implementação (ou driver) com bom desempenho. Com o Direct3D, o desenvolvedor deve gerenciar os recursos de hardware de forma independente; no entanto, a implementação é mais simples e os desenvolvedores têm flexibilidade para alocar recursos da maneira mais eficiente possível para seus aplicativos.
Até cerca de 2005, outra diferença funcional entre as APIs era a maneira como tratavam a renderização de texturas. O método Direct3D ( SetRenderTarget()) é conveniente, enquanto as versões anteriores do OpenGL exigiam a manipulação de buffers de pixel (buffers P). Isso era complicado e arriscado: se o caminho de código usado em um programa fosse diferente daquele antecipado por um fabricante de driver, o código voltaria para a renderização do software, causando uma queda substancial de desempenho. No entanto, o amplo suporte para a extensão de objetos de buffer de quadro , que fornecia um equivalente OpenGL do método Direct3D, abordou com êxito essa lacuna, e o recurso de destino de renderização do OpenGL o aproximou do Direct3D nesse aspecto.
Com exceção de algumas pequenas diferenças funcionais que foram abordadas principalmente ao longo dos anos, as duas APIs fornecem quase o mesmo nível de função. Os fabricantes de hardware e software geralmente respondem rapidamente às mudanças no DirectX , por exemplo, requisitos de processador de pixel e shader no DirectX 9 para processar processadores no DirectX 10, para tesselação no DirectX 11. Em contraste, novos recursos no OpenGL são geralmente implementados primeiro pelos fornecedores e depois aplicada retroativamente ao padrão.
atuação
Pouco depois do estabelecimento do Direct3D e do OpenGL como bibliotecas gráficas viáveis (por volta de 1995), a Microsoft e a SGI se envolveram no que foi chamado de " API Wars". Grande parte do argumento girava em torno de qual API oferecia desempenho superior. Esta questão era relevante devido ao custo muito alto de processadores gráficos dedicados durante esse tempo, o que significava que o mercado consumidor estava usando renderizadores de software implementados pela Microsoft para Direct3D e OpenGL.
Debate inicial
Os softwares de negócios para DOS , como o AutoCAD, e os jogos para DOS, como o Quake da id Software , originalmente tiveram que ser otimizados para rodar em muitos chipsets gráficos diferentes. Quando fabricantes de hardware como a 3Dlabs (membro do OpenGL Architecture Review Board ) criaram aceleradores gráficos compatíveis com OpenGL (por exemplo, chip GLint), desenvolvedores como John Carmack da id Software otimizaram seus produtos para OpenGL. À medida que os ambientes de usuário multitarefa, como o Windows e o X Window System (X11) em sistemas semelhantes ao Unix , tornaram - se predominantes, a relevância desse hardware diminuiu.
A Microsoft comercializou o Direct3D como mais rápido com base em comparações internas de desempenho dessas duas bibliotecas de software. O déficit de desempenho foi atribuído à especificação e conformidade rigorosas exigidas do OpenGL. Essa percepção foi mudada na conferência do Grupo de Interesse Especial em GRÁFICOS e Técnicas Interativas ( SIGGRAPH ) de 1996 . Naquela época, a Silicon Graphics (SGI) desafiou a Microsoft com sua própria implementação de software Windows otimizada de OpenGL, chamada CosmoGL, que em várias demos igualou ou excedeu o desempenho do Direct3D. Para a SGI, este foi um marco crítico, pois mostrou que o fraco desempenho de renderização do software OpenGL se devia à implementação do OpenGL de referência da Microsoft, e não a alegadas falhas de design no OpenGL.
Em contraste, a renderização de software pela API 3D era amplamente irrelevante para os aplicativos Direct3D e OpenGL. Poucos aplicativos DirectX usaram a renderização de software do Direct3D, preferindo executar sua própria renderização de software usando os recursos do DirectDraw para acessar o hardware de exibição. Quanto aos aplicativos OpenGL, o suporte de hardware era esperado, e o hardware era muito mais rápido que o fallback de software pelo aplicativo OpenGL constituiu uma surpresa rude para o desenvolvedor OpenGL.
Em qualquer caso, quando a SGI demonstrou que o desempenho de renderização do software OpenGL poderia ser competitivo com o do Direct3D, a renderização do software estava rapidamente se tornando irrelevante devido à ampla disponibilidade de hardware gráfico 3D de baixo custo. Em 1998, até mesmo o acelerador gráfico S3 ViRGE era substancialmente mais rápido do que o Pentium II mais rápido executando o rasterizador MMX do Direct3D .
Marshalling
Uma diferença de desempenho mais substantiva e moderna surge por causa da estrutura dos drivers de hardware fornecidos pelos desenvolvedores de hardware. No DirectX, os drivers do fornecedor independente de hardware (IHV) são drivers do modo kernel instalados no sistema operacional. A parte do modo de usuário da API é controlada pelo tempo de execução DirectX fornecido pela Microsoft. No OpenGL, entretanto, o driver IHV é dividido em duas partes: uma parte do modo de usuário que implementa a API OpenGL e um driver do modo kernel que é chamado pela parte do modo de usuário.
Isso é um problema porque chamar as operações do modo kernel a partir do modo do usuário requer a execução de uma chamada de sistema (ou seja, fazer a CPU mudar para o modo kernel). Esta é uma operação lenta, que leva cerca de microssegundos para ser concluída. Durante esse tempo, a CPU não pode realizar nenhuma operação. Dessa forma, minimizar o número de vezes que essa operação de comutação ocorre melhoraria o desempenho. Por exemplo, se o buffer de comando da GPU estiver cheio de dados de renderização, a API pode simplesmente armazenar a chamada de renderização solicitada em um buffer temporário e, quando o buffer de comando estiver quase vazio, pode realizar uma mudança para o modo kernel e adicionar um conjunto de comandos armazenados em um lote. Isso é denominado marshalling .
Como os drivers IHV do Direct3D estão no modo kernel e o código do modo do usuário está fora do controle do IHV, não há chance de tais otimizações ocorrerem. Como o tempo de execução do Direct3D, a parte do modo de usuário que implementa a API, não pode ter conhecimento explícito do funcionamento interno do driver, ele não pode oferecer suporte eficaz ao empacotamento. Isso significa que cada chamada Direct3D que envia comandos ao hardware deve realizar uma troca de modo kernel, que, novamente, leva tempo da ordem de microssegundos para ser concluída. Isso levou a vários comportamentos relacionados ao uso do Direct3D, sendo o mais importante a necessidade de enviar grandes lotes de triângulos em uma chamada de função.
Como os drivers IHV do OpenGL têm um componente de modo de usuário, os IHVs têm a capacidade de implementar o empacotamento, melhorando assim o desempenho. Ainda há troca de modo kernel, mas o número máximo teórico de opções em implementações OpenGL é simplesmente igual ao comportamento padrão do Direct3D.
O Direct3D 10 , a versão incluída no Windows Vista , permite que partes dos drivers sejam executados no modo de usuário, possibilitando que os IHVs implementem o empacotamento, trazendo os dois de volta à paridade de desempenho relativa. O sistema OpenGL do Mac OS X é muito semelhante, onde IHVs implementam uma versão mais simples da API OpenGL (com componentes de modo de usuário e kernel), e as adições da Apple ao tempo de execução fornecem a interface direta para o código do usuário e algum trabalho básico para facilitar o trabalho dos IHVs.
Corrida para zero sobrecarga do motorista
A introdução do Mantle pela AMD aumentou a discussão sobre a modernização de APIs e a atualização de conceitos de abstração usados por todas as APIs para refletir as operações da unidade de processamento gráfico (GPU). Os fornecedores da Microsoft e do OpenGL começaram a mostrar suas visões para limitar ou remover totalmente a sobrecarga do driver (a quantidade de trabalho que a CPU precisa fazer para preparar os comandos da GPU).
Em março de 2014, a Microsoft apresentou premissas e metas básicas para o componente DirectX12 3D (que estará pronto em dezembro de 2015). Os fornecedores de OpenGL adotaram uma abordagem diferente e, durante o GDC 2014, apresentaram uma combinação de recursos obrigatórios no OpenGL 4.3 e OpenGL 4.4 ou extensões ARB já existentes, para mostrar os atalhos já presentes em implementações da Nvidia, AMD e Intel. Mais tarde, a AMD doou o Mantle ao Khronos Group , a API foi renomeada como Vulkan e agora esta é a API multiplataforma atual dedicada a reduzir a sobrecarga do driver, enquanto distribui melhor o trabalho entre vários núcleos de CPU e GPU, usando um gerenciamento unificado de núcleos de computação e sombreadores gráficos .
Durante a apresentação, o apitest foi apresentado. É uma nova ferramenta para soluções específicas de microbenchmarking para determinados problemas, enfatizando a exploração de atalhos nas APIs atuais. Ambos OpenGL 4.xe Direct3D 11 são suportados. Os resultados obtidos mostraram que o OpenGL moderno pode ser muito mais rápido do que o Direct3D 11.
Estrutura
OpenGL, originalmente projetado para então poderosas estações de trabalho SGI, inclui muitos recursos, como renderização estéreo e o subconjunto de imagens , que geralmente eram considerados de uso limitado para jogos, embora jogos estereoscópicos tenham atraído mais interesse com o desenvolvimento de monitores 3D de nível de consumidor. A API como um todo contém cerca de 250 chamadas, mas apenas um subconjunto de talvez 100 são úteis para o desenvolvimento de jogos. No entanto, nenhum subconjunto oficial específico do jogo foi definido. O MiniGL, lançado pela 3Dfx como uma medida provisória para dar suporte ao GLQuake , pode ter servido como um ponto de partida, mas recursos adicionais como o estêncil foram logo adotados pelos jogos e o suporte para o padrão OpenGL completo continuou. Hoje, as estações de trabalho e as máquinas de consumo usam as mesmas arquiteturas e sistemas operacionais e, portanto, as versões modernas do padrão OpenGL ainda incluem esses recursos, embora apenas placas de vídeo especiais para estações de trabalho os acelerem.
Extensões
O mecanismo de extensão OpenGL é provavelmente a diferença mais disputada entre as duas APIs. OpenGL inclui um mecanismo onde qualquer driver pode anunciar suas próprias extensões para a API, introduzindo assim novas funções como modos de mesclagem, novas maneiras de transferir dados para GPUs ou diferentes parâmetros de empacotamento de textura. Isso permite que novas funções sejam expostas rapidamente, mas pode causar confusão se fornecedores diferentes implementarem extensões semelhantes com APIs diferentes. Muitas dessas extensões são periodicamente padronizadas pelo OpenGL Architecture Review Board (ARB), e algumas se tornam parte essencial de futuras revisões do OpenGL.
Por outro lado, o Direct3D é especificado por apenas um fornecedor ( Microsoft ), levando a uma API mais consistente, mas negando acesso a recursos específicos do fornecedor. A tecnologia UltraShadow da NVIDIA , por exemplo, não está disponível nas APIs Direct3D no momento. Direct3D oferece suporte a extensões de formato de textura (via FourCC ). Eles eram pouco conhecidos e raramente usados, mas agora são usados para S3 Texture Compression .
Quando as placas de vídeo adicionaram suporte para pixel shaders (conhecidos no OpenGL como "fragment shaders"), o Direct3D forneceu um padrão "Pixel Shader 1.1" (PS1.1) com o qual a GeForce 3 e superior e o Radeon 8500 e superior anunciavam compatibilidade. No OpenGL, as mesmas funções foram acessadas por meio de uma variedade de extensões personalizadas.
Em teoria, a abordagem da Microsoft permite que um caminho de código suporte ambas as marcas de cartão, enquanto no OpenGL, os programadores devem escrever dois sistemas separados. Na realidade, porém, por causa dos limites no processamento de pixels dessas primeiras placas, Pixel Shader 1.1 não era nada mais do que uma versão em linguagem pseudo-assembly das extensões OpenGL específicas da NVIDIA. Na maioria das vezes, as únicas placas que reivindicaram a funcionalidade do PS 1.1 foram da NVIDIA, e isso porque elas foram construídas nativamente para isso. Quando o Radeon 8500 foi lançado, a Microsoft lançou uma atualização para Direct3D que incluía Pixel Shader 1.4, que nada mais era do que uma versão em linguagem pseudo-assembly das extensões OpenGL específicas da ATI . Os únicos cartões que reivindicaram suporte PS 1.4 foram os cartões ATI, porque eles foram projetados com o hardware preciso necessário para fazer essa funcionalidade acontecer.
Esta situação existiu apenas por um curto período de tempo em ambas as APIs. Os cartões de sombreamento de pixel de segunda geração funcionaram de maneira muito mais semelhante, com cada arquitetura evoluindo em direção ao mesmo tipo de conclusão de processamento de pixel. Como tal, Pixel Shader 2.0 permitiu um caminho de código unificado no Direct3D. Mais ou menos na mesma época, a OpenGL introduziu seu próprio vértice aprovado pelo ARB e extensões de sombreador de pixel ( GL_ARB_vertex_programe GL_ARB_fragment_program), e ambos os conjuntos de placas também suportavam esse padrão.
Comercial
Gráficos profissionais
OpenGL sempre viu mais uso no mercado gráfico profissional do que o DirectX, enquanto o DirectX é usado principalmente para jogos de computador. (O termo profissional é usado aqui para se referir à produção profissional e exibição de gráficos, como em filmes animados de computador e visualização científica, ao contrário de jogos onde os gráficos produzidos são para uso pessoal do usuário final, em vez de uso profissional.) Atualmente, o OpenGL e o DirectX têm uma grande sobreposição de funcionalidade que pode ser usada para os propósitos mais comuns, com o sistema operacional frequentemente sendo o principal critério ditando qual é usado; DirectX é a escolha comum para Windows e OpenGL para quase todo o resto. Alguns aplicativos esotéricos ainda dividem a aplicabilidade das duas APIs: fazer 3D acelerado em uma conexão de rede só é suportado diretamente pelo OpenGL com extensão OpenGL para o X Window System ( GLX ), por exemplo.
No passado, muitas placas de vídeo profissionais suportavam apenas OpenGL. A partir de 2010, praticamente todas as placas profissionais que funcionam na plataforma Windows também oferecerão suporte para Direct3D. Parte disso foi uma mudança no mercado gráfico profissional de hardware amplamente baseado em Unix, como SGIs e Suns, para sistemas baseados em PC de custo mais baixo, levando ao crescimento do Windows neste segmento de mercado, ao mesmo tempo em que oferece um novo mercado para software OpenGL em sistemas de consumidor baseados em Unix executando Linux ou Mac OS X.
A principal razão histórica para o domínio do OpenGL no mercado profissional foi o desempenho. Muitos aplicativos gráficos profissionais (por exemplo, Softimage | 3D, Alias PowerAnimator ) foram originalmente escritos em IRIS GL para estações de trabalho SGI de ponta, que eram muito mais capazes, tanto graficamente quanto em potência bruta da CPU, do que os PCs da época. Mais tarde, muitos deles foram portados para OpenGL, mesmo quando o computador pessoal estava evoluindo para um sistema poderoso o suficiente para executar alguns aplicativos gráficos profissionais. Os usuários puderam executar o Maya , por exemplo, o sucessor do Alias PowerAnimator em computadores pessoais SGIs ou Windows (e hoje em Linux, Mac OS X e Windows). A competição de preços acabou quebrando o domínio da SGI no mercado, mas a base estabelecida de engenheiros de software OpenGL e a ampliação da base de usuários do OpenGL na Apple, Linux e outros sistemas operacionais resultou em um mercado onde DirectX e OpenGL são APIs viáveis e generalizadas .
A outra razão para a vantagem histórica do OpenGL foi o marketing e o design. DirectX é um conjunto de APIs que não foram comercializados para aplicativos gráficos profissionais. Na verdade, eles nem mesmo foram projetados para tais usos. O DirectX era uma API projetada para acesso de baixo nível e alto desempenho a hardware gráfico amplamente disponível, de baixo desempenho e preço ao consumidor para fins de desenvolvimento de jogos. OpenGL é uma API 3D de propósito muito mais geral, direcionada a uma gama completa de hardware gráfico de placas gráficas de baixo custo até visualização de gráficos profissionais e científicos bem fora do alcance do consumidor médio, e fornecendo recursos que não são necessariamente exclusivos para um tipo específico de usuário.
Os desenvolvedores de jogos normalmente não exigem uma API tão ampla quanto os desenvolvedores de sistemas gráficos profissionais. Muitos jogos não precisam de planos de sobreposição, estênceis e assim por diante, embora isso não tenha impedido alguns desenvolvedores de jogos de usá-los quando disponíveis. Especificamente, os designers de jogos raramente estão interessados na invariância de pixels exigida em certas partes dos padrões OpenGL, que são altamente úteis para filmes e modelagem auxiliada por computador.
Uma vez foi feita uma tentativa de mesclar OpenGL e DirectX pela SGI e pela Microsoft. A API gráfica Fahrenheit foi projetada para reunir a capacidade de ponta do OpenGL com o amplo suporte de baixo nível do DirectX. A Microsoft acabou se retirando do projeto, nunca tendo alocado recursos suficientes para produzir sua parte do mecanismo de renderização. A mudança foi amplamente considerada como tendo o objetivo de garantir o aprisionamento dos desenvolvedores à plataforma Windows-DirectX, que seria perdida se a API Fahrenheit se tornasse a API gráfica padrão mundial de fato. No entanto, Fahrenheit levou a muitas melhorias no DirectX, e o arquiteto principal de Fahrenheit agora trabalha na Microsoft no DirectX.
Jogos
Nos primeiros dias dos jogos 3D acelerados, o desempenho e a confiabilidade eram os principais pontos de referência e várias placas aceleradoras 3D competiam entre si pelo domínio. O software foi escrito para uma marca específica de placa gráfica. No entanto, ao longo dos anos, OpenGL e Direct3D surgiram como camadas de software acima do hardware, principalmente por causa do suporte da indústria para uma biblioteca gráfica de hardware cruzado. A competição entre os dois aumentou à medida que cada desenvolvedor de jogos escolheria um ou outro.
Nos primeiros dias dos jogos 3D acelerados, a maioria dos fornecedores não fornecia um driver OpenGL completo. A razão para isso foi dupla. Em primeiro lugar, a maioria dos aceleradores orientados para o consumidor não implementou funcionalidade suficiente para acelerar adequadamente o OpenGL. Em segundo lugar, muitos fornecedores se esforçaram para implementar um driver OpenGL completo com bom desempenho e compatibilidade. Em vez disso, eles escreveram drivers MiniGL , que implementaram apenas um subconjunto de OpenGL, o suficiente para rodar GLQuake (e mais tarde outros jogos OpenGL, principalmente baseados no motor Quake). Os drivers OpenGL adequados tornaram-se mais prevalentes à medida que o hardware evoluiu e os aceleradores orientados para o consumidor alcançaram os sistemas SGI para os quais o OpenGL foi originalmente projetado. Isso seria na época do DirectX 6 ou DirectX 7.
No mundo dos consoles, APIs nativas proprietárias são dominantes, com alguns consoles (por exemplo, o PS3) fornecendo um wrapper OpenGL em torno de sua API nativa. O Xbox original oferece suporte a Direct3D 8.1 como API nativa, enquanto o Xbox 360 oferece suporte a DirectX9 como API nativa. A maioria dos desenvolvedores de console prefere usar as APIs nativas para cada console para maximizar o desempenho, tornando as comparações OpenGL e Direct3D relevantes para plataformas principalmente de PC.
Telefones celulares e outros dispositivos incorporados
OpenGL para sistemas incorporados, denominado OpenGL ES , é um subconjunto da API gráfica OpenGL 3D projetada para dispositivos incorporados . Várias versões de sistemas operacionais de smartphone suportam OpenGL ES, como Android , iOS ( iPad , iPhone , iPod Touch ), Maemo ( Nokia N900 ) e Symbian .
OpenGL ES está disponível em 6 variantes, OpenGL ES 1.0, 1.1, 2.0, 3.0, 3.1, 3.2. O lançamento do 2.0 removeu a compatibilidade com versões anteriores, devido às funções extensas de pipeline programáveis disponíveis no GL ES 2.0, sobre as funções de pipeline fixo do GL ES 1.0 e 1.1. O OpenGL ES 3.0 precisava de um novo hardware sobre o OpenGL ES 2.0, enquanto o OpenGL ES 3.1 é uma atualização de software, precisando apenas de novos drivers.
Direct3D Mobile , um derivado do Direct3D, é compatível com o Windows CE . Atualmente, todos os dispositivos Windows Phone 7 usam uma interface de usuário .NET Framework acelerada por Direct3D Mobile 9 em GPUs Adreno 200/205 integradas da Qualcomm.
O Windows Phone 8 implementa Direct3D 11 (limitado ao nível de recurso 9_3).