Muitas das respostas aqui são muito, muito boas. Mas o problema do OpenGL e Direct3D (D3D) provavelmente deve ser resolvido. E isso requer ... uma lição de história.
E antes de começarmos, eu sei muito mais sobre o OpenGL do que sobre o Direct3D . Eu nunca escrevi uma linha de código D3D na minha vida e escrevi tutoriais sobre o OpenGL. Então, o que estou prestes a dizer não é uma questão de viés. É simplesmente uma questão de história.
Nascimento de Conflito
Um dia, no início dos anos 90, a Microsoft olhou em volta. Eles viram o SNES e o Sega Genesis serem incríveis, rodando muitos jogos de ação e coisas do gênero . E eles viram o DOS . Os desenvolvedores codificaram jogos do DOS como jogos de console: direto ao metal. Ao contrário dos consoles, no entanto, onde um desenvolvedor que criou um jogo SNES sabia qual hardware o usuário teria, os desenvolvedores do DOS precisavam escrever para várias configurações possíveis. E isso é mais difícil do que parece.
E a Microsoft tinha um problema maior: o Windows. Veja, o Windows queria possuir o hardware, ao contrário do DOS, que praticamente permite que os desenvolvedores façam o que quer. É necessário possuir o hardware para ter cooperação entre aplicativos. Cooperação é exatamente o que os desenvolvedores de jogos detestam, pois consome recursos preciosos de hardware que eles poderiam estar usando para serem incríveis.
Para promover o desenvolvimento de jogos no Windows, a Microsoft precisava de uma API uniforme, de baixo nível, executada no Windows sem ser desacelerada por ela e, acima de tudo, entre hardwares . Uma única API para todos os gráficos, som e hardware de entrada.
Assim, o DirectX nasceu.
Os aceleradores 3D nasceram alguns meses depois. E a Microsoft teve um problema. Veja, o DirectDraw, o componente gráfico do DirectX, lidava apenas com gráficos 2D: alocando memória gráfica e fazendo bit-blits entre diferentes seções alocadas da memória.
Por isso, a Microsoft comprou um pouco de middleware e transformou-o no Direct3D versão 3. Ele foi universalmente criticado. E com boas razões; olhar para o código D3D v3 é como olhar para a Arca da Aliança.
O velho John Carmack, da Id Software, deu uma olhada no lixo e disse: "Dane-se!" e decidiu escrever para outra API: OpenGL.
Veja, outra parte da besta de muitas cabeças da Microsoft estava ocupada trabalhando com a SGI em uma implementação OpenGL para Windows. A idéia aqui era julgar os desenvolvedores de aplicativos GL típicos: aplicativos de estação de trabalho. Ferramentas de CAD, modelagem, esse tipo de coisa. Jogos eram a coisa mais distante em sua mente. Isso era basicamente uma coisa do Windows NT, mas a Microsoft decidiu adicioná-lo ao Win95 também.
Como forma de atrair desenvolvedores de estações de trabalho para o Windows, a Microsoft decidiu tentar suborná-los com acesso a essas novas placas gráficas 3D. A Microsoft implementou o protocolo Installable Client Driver: um fabricante de placa de vídeo pode substituir a implementação do software OpenGL da Microsoft por uma baseada em hardware. O código poderia usar automaticamente apenas uma implementação OpenGL de hardware, se estivesse disponível.
No início, os videocards no nível do consumidor não tinham suporte para o OpenGL. Isso não impediu Carmack de apenas portar o Quake para o OpenGL (GLQuake) em sua estação de trabalho SGI. Como podemos ler no leia-me do GLQuake:
Teoricamente, o glquake será executado em qualquer OpenGL compatível que ofereça suporte às extensões de objetos de textura, mas, a menos que seja um hardware muito poderoso que acelere tudo o necessário, o jogo não será aceitável. Se precisar passar por qualquer caminho de emulação de software, o desempenho provavelmente ficará abaixo de um quadro por segundo.
No momento (março de 97), o único hardware opengl padrão capaz de reproduzir glquake razoavelmente é um realizador intergraph, que é um cartão MUITO caro. O 3dlabs vem melhorando significativamente seu desempenho, mas com os drivers disponíveis ainda não é bom o suficiente para jogar. Alguns dos drivers 3dlabs atuais para placas de brilho e permedia também podem travar o NT ao sair de uma execução em tela cheia, por isso não recomendo executar o glquake no hardware da 3dlabs.
O 3dfx forneceu um opengl32.dll que implementa tudo o que o glquake precisa, mas não é uma implementação opengl completa. É improvável que outras aplicações opengl funcionem com ela, portanto, considere-a basicamente um "driver para glquake".
Este foi o nascimento dos drivers miniGL. Eles evoluíram para implementações completas do OpenGL eventualmente, à medida que o hardware se tornou poderoso o suficiente para implementar a maioria das funcionalidades do OpenGL no hardware. A nVidia foi a primeira a oferecer uma implementação completa do OpenGL. Muitos outros fornecedores enfrentaram dificuldades, e essa é uma das razões pelas quais os desenvolvedores preferem o Direct3D: eles são compatíveis com uma ampla gama de hardware. Eventualmente, apenas a nVidia e a ATI (agora AMD) permaneceram, e ambas tiveram uma boa implementação do OpenGL.
OpenGL Ascendant
Assim, o cenário está montado: Direct3D vs. OpenGL. É realmente uma história incrível, considerando o quão ruim o D3D v3 foi.
O OpenGL Architectural Review Board (ARB) é a organização responsável pela manutenção do OpenGL. Eles emitem várias extensões, mantêm o repositório de extensões e criam novas versões da API. O ARB é um comitê formado por muitos dos participantes da indústria gráfica, além de alguns fabricantes de sistemas operacionais. A Apple e a Microsoft foram em vários momentos um membro do ARB.
O 3Dfx é lançado com o Voodoo2. Este é o primeiro hardware que pode executar multi-extensões, algo que o OpenGL não podia fazer antes. Embora o 3Dfx fosse fortemente contra o OpenGL, a NVIDIA, fabricante do próximo chip gráfico de várias estruturas (o TNT1), adorou. Portanto, o ARB emitiu uma extensão: GL_ARB_multitexture, que permitiria o acesso à multitexturing.
Enquanto isso, o Direct3D v5 sai. Agora, o D3D se tornou uma API real , em vez de algo que um gato pode vomitar. O problema? Sem multi-extensão.
Opa
Agora, isso não machucaria tanto quanto deveria, porque as pessoas não usavam muito a multi-extensão. Não diretamente. A multi-extensão prejudicou bastante o desempenho e, em muitos casos, não valeu a pena em comparação com a passagem múltipla. E, é claro, os desenvolvedores de jogos adoram garantir que seus jogos funcionem em hardware mais antigo, que não possuía múltiplas estruturas, tantos jogos enviados sem ele.
D3D, portanto, recebeu uma suspensão.
O tempo passa e a NVIDIA implementa a GeForce 256 (não a GeForce GT-250; a primeira GeForce), acabando com a competição em placas gráficas pelos próximos dois anos. O principal ponto de venda é a capacidade de realizar transformações e iluminação de vértices (T&L) em hardware. Além disso, a NVIDIA amava tanto o OpenGL que seu mecanismo de T&L era efetivamente o OpenGL. Quase literalmente; pelo que entendi, alguns de seus registradores realmente consideraram os enumeradores do OpenGL diretamente como valores.
O Direct3D v6 é lançado. Por fim, com várias estruturas, mas ... sem T&L de hardware. O OpenGL sempre teve um pipeline de T&L, embora antes dos 256 ele fosse implementado em software. Por isso, foi muito fácil para a NVIDIA converter sua implementação de software em uma solução de hardware. Não seria até o D3D v7 até que o D3D finalmente tivesse suporte a T&L de hardware.
Amanhecer dos Shaders, Crepúsculo do OpenGL
Então, o GeForce 3 foi lançado. E muitas coisas aconteceram ao mesmo tempo.
A Microsoft decidiu que não se atrasariam novamente. Então, em vez de olhar para o que a NVIDIA estava fazendo e depois copiá-lo após o fato, eles assumiram a posição surpreendente de ir até eles e conversar com eles. E então eles se apaixonaram e tiveram um pequeno console juntos.
Um divórcio confuso se seguiu mais tarde. Mas isso é para outra hora.
O que isso significava para o PC era que o GeForce 3 saiu simultaneamente com o D3D v8. E não é difícil ver como o GeForce 3 influenciou os shaders do D3D 8. Os shaders de pixel do Shader Model 1.0 eram extremamente específicos para o hardware da NVIDIA. Não houve nenhuma tentativa de abstrair o hardware da NVIDIA; O SM 1.0 foi exatamente o que a GeForce 3 fez.
Quando a ATI começou a entrar na corrida de placas gráficas de desempenho com a Radeon 8500, houve um problema. O pipeline de processamento de pixels do 8500 era mais poderoso do que o material da NVIDIA. Então a Microsoft lançou o Shader Model 1.1, que basicamente era "O que o 8500 faz".
Isso pode parecer uma falha da parte do D3D. Mas fracasso e sucesso são questões de graus. E um fracasso épico estava acontecendo na terra do OpenGL.
A NVIDIA amava o OpenGL, então, quando a GeForce 3 chegou, eles lançaram uma série de extensões OpenGL. Extensões proprietárias OpenGL: somente NVIDIA. Naturalmente, quando o 8500 apareceu, ele não podia usar nenhum deles.
Veja, pelo menos no D3D 8 land, você pode executar seus shaders SM 1.0 no hardware da ATI. Claro, você tinha que escrever novos shaders para tirar proveito do frescor do 8500, mas pelo menos seu código funcionava .
Para ter sombreadores de qualquer tipo no Radeon 8500 no OpenGL, a ATI precisou escrever várias extensões do OpenGL. Extensões OpenGL proprietárias : somente ATI. Então, você precisava de um caminho de código da NVIDIA e de ATI, apenas para ter sombreadores .
Agora, você pode perguntar: "Onde estava o OpenGL ARB, cujo trabalho era manter o OpenGL atualizado?" Onde muitas comissões frequentemente acabam: sendo estúpidas.
Veja, eu mencionei ARB_multitexture acima porque isso influencia profundamente tudo isso. O ARB parecia (do ponto de vista de alguém de fora) querer evitar completamente a idéia de shaders. Eles concluíram que, se colocassem configurabilidade suficiente no pipeline de função fixa, poderiam igualar a capacidade de um pipeline de shader.
Então o ARB lançou extensão após extensão. Cada extensão com as palavras "texture_env" continha mais uma tentativa de corrigir esse design antigo. Verifique o registro: entre as extensões ARB e EXT, foram feitas oito dessas extensões. Muitos foram promovidos para as versões principais do OpenGL.
A Microsoft fazia parte do ARB naquele momento; eles saíram na época em que o D3D 9 foi atingido. Portanto, é perfeitamente possível que eles estivessem trabalhando para sabotar o OpenGL de alguma forma. Pessoalmente, duvido dessa teoria por dois motivos. Primeiro, eles precisariam obter ajuda de outros membros da ARB para fazer isso, já que cada membro recebe apenas um voto. E o mais importante: o ARB não precisava da ajuda da Microsoft para estragar tudo. Veremos mais evidências disso.
Eventualmente, o ARB, provavelmente sob ameaça da ATI e da NVIDIA (ambos os membros ativos), acabou puxando a cabeça por tempo suficiente para fornecer shaders reais no estilo de montagem.
Quer algo ainda mais estúpido?
Termos e condições de hardware. Algo que o OpenGL teve primeiro . Bem, é interessante. Para obter o máximo desempenho possível dos T&L de hardware, você precisa armazenar seus dados de vértice na GPU. Afinal, é a GPU que realmente deseja usar seus dados de vértice.
No D3D v7, a Microsoft introduziu o conceito de Vertex Buffers. Essas são faixas alocadas de memória da GPU para armazenar dados de vértice.
Quer saber quando o OpenGL conseguiu o equivalente disso? Ah, a NVIDIA, sendo uma amante de tudo o que o OpenGL (desde que sejam extensões proprietárias da NVIDIA), lançou a extensão do alcance da matriz de vértices quando a GeForce 256 foi lançada pela primeira vez. Mas quando o ARB decidiu fornecer funcionalidade semelhante?
Dois anos depois . Isso foi depois que eles aprovaram sombreadores de vértice e fragmento (pixel na linguagem D3D). Foi esse o tempo que o ARB levou para desenvolver uma solução de plataforma cruzada para armazenar dados de vértices na memória da GPU. Novamente, algo que os T&L de hardware precisam para atingir o desempenho máximo.
Um idioma para estragá-los todos
Portanto, o ambiente de desenvolvimento do OpenGL foi quebrado por um tempo. Sem shaders de hardware cruzado, sem armazenamento de vértice de GPU de hardware cruzado, enquanto os usuários do D3D desfrutavam de ambos. Poderia piorar?
Você ... você poderia dizer isso. Entre no 3D Labs .
Quem são eles, você pode perguntar? Eles são uma empresa extinta que considero os verdadeiros assassinos do OpenGL. Certamente, a inaptidão geral do ARB tornou o OpenGL vulnerável quando deveria ter o D3D. Mas o 3D Labs é talvez o maior motivo para o estado atual do mercado do OpenGL. O que eles poderiam ter feito para causar isso?
Eles projetaram a OpenGL Shading Language.
Veja, 3D Labs era uma empresa moribunda. Suas GPUs caras estavam sendo marginalizadas pela crescente pressão da NVIDIA no mercado de estações de trabalho. E, diferentemente da NVIDIA, o 3D Labs não tinha presença no mercado convencional; se a NVIDIA vencesse, eles morreriam.
O que eles fizeram.
Portanto, em uma tentativa de permanecer relevante em um mundo que não queria seus produtos, o 3D Labs apareceu em uma Game Developer Conference exibindo apresentações para algo que chamou de "OpenGL 2.0". Isso seria uma reescrita completa e completa da API do OpenGL. E isso faz sentido; havia muito cruft na API do OpenGL na época (nota: esse cruft ainda existe). Veja como o carregamento e a ligação de textura funcionam; é semi-arcano.
Parte de sua proposta era uma linguagem de sombreamento. Naturalmente. No entanto, diferentemente das extensões ARB atuais de plataforma cruzada, o idioma de sombreamento era "alto nível" (C é de alto nível para um idioma de sombreamento. Sim, na verdade).
Agora, a Microsoft estava trabalhando em sua própria linguagem de sombreamento de alto nível. Que eles, em toda a imaginação coletiva da Microsoft, chamaram ... de linguagem de sombreamento de alto nível (HLSL). Mas a abordagem deles era fundamentalmente diferente para os idiomas.
O maior problema com a linguagem de sombreamento do 3D Labs foi que ele estava embutido. Veja, HLSL era um idioma definido pela Microsoft. Eles lançaram um compilador para ele e ele gerou o código de montagem do Shader Model 2.0 (ou modelos de shader posteriores), que você alimentaria no D3D. Nos dias do D3D v9, o HLSL nunca foi tocado diretamente pelo D3D. Foi uma boa abstração, mas era puramente opcional. E um desenvolvedor sempre teve a oportunidade de ir atrás do compilador e ajustar a saída para obter o desempenho máximo.
A linguagem do 3D Labs não tinha nada disso. Você deu ao motorista a linguagem C, e ela produziu um sombreador. Fim da história. Não é um shader de montagem, não é algo que você alimenta outra coisa. O objeto OpenGL real que representa um shader.
O que isso significava é que os usuários do OpenGL estavam abertos aos caprichos dos desenvolvedores que estavam apenas aprendendo a compilar linguagens do tipo assembly. Os erros do compilador eram comuns no recém-batizado OpenGL Shading Language (GLSL). O que é pior: se você conseguiu que um shader compilasse corretamente em várias plataformas (sem façanha), você ainda estava sujeito aos otimizadores do dia. Que não eram tão ótimos quanto poderiam ser.
Embora essa fosse a maior falha no GLSL, não era a única falha. De longe .
No D3D e nas linguagens assembly mais antigas do OpenGL, era possível misturar e combinar sombreadores de vértice e fragmento (pixel). Desde que eles se comuniquem com a mesma interface, você poderá usar qualquer shader de vértice com qualquer shader de fragmento compatível. E havia até níveis de incompatibilidade que eles podiam aceitar; um shader de vértice pode escrever uma saída que o shader de fragmento não leu. E assim por diante.
GLSL não tinha nada disso. Os vértices e os shaders de fragmentos foram fundidos no que o 3D Labs chamou de "objeto de programa". Portanto, se você quiser compartilhar programas de vértice e fragmento, precisará criar vários objetos de programa. E isso causou o segundo maior problema.
Veja, o 3D Labs achou que estavam sendo espertos. Eles basearam o modelo de compilação do GLSL em C / C ++. Você pega um .c ou .cpp e o compila em um arquivo de objeto. Então você pega um ou mais arquivos de objeto e os vincula a um programa. É assim que o GLSL compila: você compila seu shader (vértice ou fragmento) em um objeto shader. Em seguida, você coloca esses objetos de sombreamento em um objeto de programa e os vincula para formar seu programa real.
Embora isso tenha permitido idéias interessantes em potencial, como ter shaders de "biblioteca" que continham código extra que os shaders principais poderiam chamar, o que na prática significava que os shaders eram compilados duas vezes . Uma vez no estágio de compilação e no estágio de vinculação. O compilador da NVIDIA, em particular, era conhecido por basicamente executar a compilação duas vezes. Não gerou algum tipo de código de objeto intermediário; apenas o compilou uma vez e jogou fora a resposta, depois a compilou novamente no momento do link.
Portanto, mesmo se você quiser vincular seu shader de vértice a dois shaders de fragmento diferentes, precisará compilar muito mais do que no D3D. Especialmente porque a compilação de uma linguagem do tipo C foi feita offline , não no início da execução do programa.
Houve outros problemas com o GLSL. Talvez pareça errado culpar o 3D Labs, já que o ARB finalmente aprovou e incorporou o idioma (mas nada mais da iniciativa "OpenGL 2.0"). Mas foi ideia deles.
E aqui está a parte realmente triste: o 3D Labs estava certo (principalmente). O GLSL não é uma linguagem de sombreamento baseada em vetores, como era o HLSL na época. Isso ocorreu porque o hardware do 3D Labs era escalar (semelhante ao hardware moderno da NVIDIA), mas eles estavam certos na direção que muitos fabricantes de hardware seguiram com seu hardware.
Eles estavam certos em usar um modelo de compilação online para uma linguagem de "alto nível". O D3D até mudou para isso eventualmente.
O problema era que o 3D Labs estava certo na hora errada . E, ao tentar convocar o futuro muito cedo, tentando ser à prova do futuro, eles descartam o presente . Parece semelhante a como o OpenGL sempre teve a possibilidade de funcionalidade de T&L. Exceto que o pipeline de T&L do OpenGL ainda era útil antes do T&L de hardware, enquanto o GLSL era um passivo antes que o mundo o alcançasse.
GLSL é uma boa linguagem agora . Mas por enquanto? Foi horrível. E o OpenGL sofreu por isso.
Caindo em direção à apoteose
Enquanto eu sustento que o 3D Labs deu o golpe fatal, foi o próprio ARB quem acionou o último prego no caixão.
Esta é uma história da qual você já deve ter ouvido falar. Na época do OpenGL 2.1, o OpenGL estava com um problema. Tinha um monte de lixo legado. A API não era mais fácil de usar. Havia 5 maneiras de fazer as coisas, e nenhuma idéia de qual era a mais rápida. Você pode "aprender" o OpenGL com tutoriais simples, mas realmente não aprendeu a API do OpenGL que oferece desempenho e poder gráfico reais.
Então o ARB decidiu tentar outra reinvenção do OpenGL. Isso foi semelhante ao "OpenGL 2.0" do 3D Labs, mas melhor porque o ARB estava por trás dele. Eles chamavam de "Longs Peak".
O que há de tão ruim em levar algum tempo para melhorar a API? Isso foi ruim porque a Microsoft havia se deixado vulnerável. Veja, isso foi na época da troca do Vista.
Com o Vista, a Microsoft decidiu instituir algumas alterações muito necessárias nos drivers de vídeo. Eles forçaram os motoristas a enviar ao SO para virtualização da memória gráfica e várias outras coisas.
Embora se possa debater os méritos disso ou se isso era realmente possível, o fato permanece o seguinte: a Microsoft considerou o D3D 10 apenas o Vista (e acima). Mesmo se você tivesse um hardware compatível com o D3D 10, não poderia executar aplicativos do D3D 10 sem também executar o Vista.
Você também deve se lembrar que o Vista ... hum, digamos que não deu certo. Então, você tinha um sistema operacional com baixo desempenho, uma nova API que era executada apenas naquele sistema operacional e uma nova geração de hardware que precisava que a API e o SO fizessem algo além de ser mais rápido que a geração anterior.
No entanto, os desenvolvedores podem acessar os recursos da classe D3D 10 via OpenGL. Bem, eles poderiam se o ARB não estivesse ocupado trabalhando em Longs Peak.
Basicamente, o ARB passou um bom ano e meio a dois anos em trabalho para melhorar a API. Quando o OpenGL 3.0 foi lançado, a adoção do Vista terminou, o Win7 estava ao virar da esquina para colocar o Vista atrás deles, e a maioria dos desenvolvedores de jogos não se importava com os recursos da classe D3D-10. Afinal, o hardware do D3D 10 executava aplicativos do D3D 9 muito bem. E com o surgimento de portas de PC para console (ou desenvolvedores de PCs saltando de navio para console de desenvolvimento. Faça a sua escolha), os desenvolvedores não precisavam dos recursos da classe D3D 10.
Agora, se os desenvolvedores tivessem acesso a esses recursos anteriormente via OpenGL em máquinas WinXP, o desenvolvimento do OpenGL poderia ter recebido uma chance muito necessária. Mas o ARB perdeu a oportunidade. E você quer saber a pior parte?
Apesar de passar dois anos preciosos tentando reconstruir a API do zero ... eles ainda falharam e voltaram ao status quo (exceto por um mecanismo de reprovação).
Portanto, o ARB não apenas perdeu uma importante janela de oportunidade, como também não fez a tarefa que os fez perder essa chance. Praticamente falha épica por toda parte.
E esse é o conto do OpenGL vs. Direct3D. Uma história de oportunidades perdidas, estupidez grosseira, cegueira voluntária e tolice simples.