Eu realmente preciso usar uma API de gráficos?

22

É necessário usar APIs gráficas para obter aceleração de hardware em um jogo 3D? Até que ponto é possível liberar dependências para APIs de placas gráficas como OpenGL, DirectX , CUDA, OpenCL ou qualquer outra coisa?

Posso criar minha própria API ou biblioteca gráfica para o meu jogo? Mesmo que seja difícil, é teoricamente possível que meu aplicativo 3D entre em contato com o driver gráfico de forma independente e renderize tudo na GPU?

Rubayet Bijoy
fonte
30
CUDA e OpenCL não são APIs de gráficos.
Sabonete
4
Para "entrar em contato com o driver gráfico de forma independente", você sempre precisa de uma API!
1911 Josef
21
Não, você não precisa de uma API para gráficos, pode acessar o driver diretamente, ele nem para por aí, pode escrever seu próprio driver para falar diretamente com o hardware, se desejar. Mas sua próxima pergunta é muito mais importante: "Devo usar uma API de gráficos?", Sim, sim, você deveria.
22415 Kevin
5
Vocês percebem que uma API também é feita em um ponto? O driver é exposto a chamadas externas que uma API implementa e agrupa em agradáveis ​​chamadas de API fáceis de usar.
22415 Kevin
3
Não há uma placa gráfica (ou SO, neste momento) que não suporte o OpenGL. Ele literalmente roda em tudo, portanto, se o único motivo pelo qual você não deseja usá-lo é para "compatibilidade", é uma preocupação completamente infundada.
Sandalfoot

Respostas:

39

Acho que muitas das respostas perdem um ponto importante: você pode escrever aplicativos que acessam hardware diretamente, mas não em sistemas operacionais modernos . Não é apenas um problema de tempo, mas um problema de "você não tem escolha".

Windows, Linux, OSX, etc., todos proíbem o acesso direto do hardware a aplicativos arbitrários. Isso é importante por motivos de segurança: você não deseja que nenhum aplicativo aleatório consiga ler a memória arbitrária da GPU pelo mesmo motivo que não deseja que nenhum aplicativo aleatório consiga ler a memória do sistema. Coisas como o buffer de quadros da sua conta bancária ou o que estiver na memória da GPU. Você quer esse material isolado e protegido e o acesso controlado pelo seu sistema operacional.

Somente os drivers podem conversar diretamente com a maioria dos hardwares, e a única maneira de conversar com o driver é através do HAL exposto do sistema operacional e da interface proprietária e incompatível de cada driver. Essa interface do driver não será apenas diferente para cada fornecedor, mas também diferirá entre as versões do próprio driver, tornando quase impossível conversar diretamente com a interface em um aplicativo de consumidor. Essas camadas geralmente são cobertas por controles de acesso que restringem ainda mais a capacidade de um aplicativo acessá-los.

Portanto, não, seu jogo não pode apenas usar o hardware diretamente, a menos que você esteja direcionando apenas sistemas operacionais inseguros como o DOS, e sua única opção viável para um jogo em sistemas operacionais de consumidor modernos é segmentar uma API pública como DirectX, OpenGL ou Vulkan.

Sean Middleditch
fonte
Parabéns, bom complemento para a discussão. Você aprende algo novo a cada dia.
Engenheiro de
1
O que restringe a sua escolha de escrever um módulo do kernel para acessar o hardware? Além disso, se você estiver direcionando um único cartão (o da sua máquina), os problemas de compatibilidade desaparecerão; embora ainda esteja longe de ser uma coisa trivial; mas dentro do reino dos possíveis, com motoristas de engenharia reversa; especialmente se você tiver apenas um escopo limitado do que deseja fazer com o cartão.
Joel Bosveld
1
A assinatura do driver em muitos sistemas operacionais dificulta a distribuição do seu módulo. Você certamente pode criar todos os tipos de drivers e hacks de sistema operacional localmente, mas não poderá distribuir seu jogo muito amplamente, o que eu assumi ser um aspecto desejado, já que o OP perguntou sobre criar um jogo real, não um sentido. demonstração de tecnologia. : p
Sean Middleditch
27

Praticamente é necessário, sim. É necessário porque, a menos que você queira passar anos escrevendo o que é essencialmente o código do driver para as diversas configurações de hardware disponíveis, você precisa usar uma API que se unifique aos drivers existentes, escritos pelos fornecedores de GPU, para todos os sistemas operacionais e hardware populares.

A única alternativa realista é que você não usa a aceleração 3D e prefere a renderização de software que, desde que seja escrita em algo verdadeiramente portátil como C, será capaz de rodar em praticamente qualquer sistema / dispositivo. Isso é bom para jogos menores ... algo como SDL é adequado para esse fim ... existem outros por aí também. Mas isso não tem recursos 3D inerentes, então você terá que construí-los você mesmo ... o que não é uma tarefa trivial.

Lembre-se também de que a renderização da CPU é ineficiente e apresenta baixo desempenho em comparação às GPUs.

Engenheiro
fonte
11
Para aproveitar o benefício do OP: a renderização de software também apresenta desempenho significativamente menor. Embora isso possa não importar em termos de taxa de quadros para jogos mais simples, duvido que muitos clientes apreciem a redução na duração da bateria que sofrem, porque a renderização do software mantém a CPU muito mais ativa do que seria necessário.
Chris Hayes
1
Bom ponto, @ChrisHayes ... editado para adicionar. Às vezes, assume-se que essas coisas são óbvias.
Engenheiro de
1
Parece que seu primeiro parágrafo está dizendo que tecnicamente é não necessário o uso de uma API. Claro, economiza uma quantidade enorme de tempo do programador, talvez mais do que uma pessoa tenha a oferecer, mas não é necessário . Como seria de esperar, a menos que haja algum tipo de verificação criptográfica entre o driver da placa de vídeo e as bibliotecas de software de nível superior.
David Z
5
@DavidZ Você já escreveu um driver? Você sabe como é fazer interface com hardware complexo quando você nem tem as especificações, mesmo quando os engenheiros empregados pelo fabricante da placa levaram meses para desenvolver o driver? Agora multiplique por quantas arquiteturas você precisar suportar. Se eu disser: "É impossível escalar o Everest sem equipamento", é claro que há uma chance que você pode, mas é realmente uma chance minúscula ... por que alguém argumentaria a respeito?
Engenheiro de
1
Pergunte ao OP por que eles querem argumentar ;-) mas especialmente após a edição, é bem claro que é isso que eles querem.
David Z
8

APIs como OpenGL ou DirectX são parcialmente implementadas pelo sistema operacional e parcialmente implementadas pelo próprio driver gráfico.

Isso significa que, quando você deseja criar sua própria API de baixo nível, que utiliza os recursos das GPUs modernas, você precisa essencialmente escrever um próprio driver gráfico. Certificar-se de que seu driver funcione com todas as placas gráficas comuns seria um grande desafio, principalmente porque os fornecedores geralmente não são muito abertos com suas especificações.

Philipp
fonte
6

Inicialize seu PC no MS-DOS. Em seguida, usando sua cópia da Enciclopédia de Programadores de Jogos para PC , você pode gravar diretamente nos registros VESA da placa e na memória de vídeo. Ainda tenho o código que escrevi há 20 anos para fazer isso e renderizar 3D rudimentar em software.

Como alternativa, você pode apenas usar o DirectX; é uma camada de abstração muito fina e também permite gravar diretamente em buffers de vídeo e depois trocá-los na tela.

Há também a abordagem extrema de criar seu próprio hardware de vídeo .

pjc50
fonte
4

As outras respostas respondem bem à sua pergunta principal: tecnicamente, é possível, mas na prática, se seu objetivo é ampliar sua base de clientes, você está realmente fazendo o oposto. Ao desperdiçar uma enorme quantidade de trabalho no suporte a milhares de configurações diferentes de hardware e sistema operacional, você precisa dar suporte.

No entanto, isso não significa que você precise estar 100% dependente de uma API específica. Você sempre pode codificar sua própria camada de abstração e depois trocar as implementações mais específicas (por exemplo, uma implementação do DirectX, uma implementação do OpenGL, ...) dentro e fora.

Mesmo assim, provavelmente não vale a pena. Basta escolher algo que funcione bem o suficiente para seus propósitos e terminar com isso. Você é um criador de jogos independente - precisa se concentrar nas coisas que fazem o jogo, não nas minúcias. Apenas faça o jogo!

Luaan
fonte
4

Em resumo: teoricamente você pode, mas é inviável e não terá nenhuma vantagem. As limitações das APIs hoje se tornam menores a cada dia, você tem CUDA, OpenCL e shaders. Portanto, ter controle total não é mais um problema.


Explicação mais completa:

Responder a este é um sim chato . A verdadeira questão é por quê ?

Eu mal imagino por que você gostaria de fazer isso a não ser para fins de aprendizado. Você precisa saber que, em algum momento, os desenvolvedores tiveram a liberdade de fazer qualquer coisa com suas implementações de processamento de CPU, todos tinham sua própria API, eles estavam no controle de tudo no "pipeline". Com a introdução de pipeline fixo e GPUs, todos mudaram ..

Com as GPUs, você obtém um desempenho "melhor", mas perde muita liberdade. Os desenvolvedores gráficos estão se esforçando para recuperar essa liberdade. Portanto, mais pipeline de personalização todos os dias. Você pode fazer quase qualquer coisa usando CUDA / OpenCL e até shaders, sem tocar nos drivers.

concept3d
fonte
1

Você quer falar com o hardware. Você precisa usar uma maneira de conversar com o hardware. Dessa forma, é a interface para o hardware. É isso que OpenGL, DirectX, CUDA, OpenCL e o que mais for.

Se você chegar a um nível inferior, estará apenas usando uma interface de nível inferior, mas ainda estará usando uma interface, apenas uma que não funcione com tantas placas diferentes quanto a de nível superior.

Peter - Unban Robert Harvey
fonte
1

Para obter a Aceleração de hardware 3D sem usar uma API tradicional, é necessário escrever seu próprio código para duplicar a funcionalidade do driver gráfico. Portanto, a melhor maneira de aprender como fazer isso é examinar o código do driver gráfico.

Para placas NVIDIA, você deve examinar o projeto nouveau de código aberto . Eles têm uma coleção de ótimos recursos aqui .

Para outras marcas de placas gráficas, você pode encontrar projetos e documentação semelhantes.

Observe que, como mencionado em outras respostas, os sistemas operacionais mais modernos impedirão que os programas do espaço do usuário acessem diretamente o hardware; portanto, você precisará escrever seu código e instalá-lo como um driver de sistema operacional. Como alternativa, você pode usar o sistema operacional FreeDOS, que não possui essas restrições, e deve permitir (teoricamente) acessar diretamente o hardware e escrever um programa regular que renderiza gráficos acelerados por hardware 3D. Observe que, mesmo aproveitando o código de um driver gráfico de código aberto existente, isso seria uma tremenda quantidade de trabalho não trivial (e, pelo que sei, nunca foi feito e, devido a várias razões, pode não ser realmente tecnicamente possível).

John
fonte
1

Livrar-se do DirectX ou OpenGl não removeria dependências, introduziria mais delas. As outras respostas já contêm vários pontos positivos de por que nem sequer é possível falar diretamente com o hardware gráfico (pelo menos não é viável), mas minha primeira resposta seria: Se você realmente escrevesse uma biblioteca que abstraísse todas as imagens 3D comuns hardware gráfico em uma única API, você efetivamente reescreveria o DirectX / OpenGl. Se você usasse seu código para escrever um jogo, teria adicionado sua nova biblioteca como uma nova dependência, assim como agora você tem o DirectX / OpenGl como uma dependência.

Ao usar o DirectX ou o OpenGl, suas dependências estão basicamente dizendo "Esse código depende de uma biblioteca para fornecer o código que explica como executar determinados comandos em diferentes placas gráficas". Se você ficasse sem essa biblioteca, introduziria a dependência de "Esse código depende do hardware gráfico que se comporta exatamente da mesma maneira que o hardware existente quando eu construí o jogo".

Abstrações como o OpenGl ou o DirectX permitem que os fabricantes de hardware forneçam códigos próprios (drivers) que levam a uma base de código comum; portanto, os jogos têm maior probabilidade de rodar em hardware que nem existia quando o jogo foi escrito.

Lars Kokemohr
fonte
0

Primeiro de tudo, CUDA e OpenCL não são APIs de gráficos. Eles são apis de computação.

O problema de escrever sua própria API gráfica é que ela é muito complexa. Você pode interagir diretamente com o hardware, mas não há garantia de que, se funcionar em um sistema com CPU X, GPU X, quantidade de RAM e sistema operacional X, ele funcionará em um sistema com CPU Y, GPU Y, etc. Um bom ponto é que o DirectX funciona com drivers no modo kernel. Está enraizado no kernel. Além disso, as APIs gráficas não são construídas para suportar GPUs. As GPUs (e seus drivers) são criadas para suportá-las. Portanto, você praticamente não pode criar uma API gráfica, a menos que crie seu próprio sistema operacional e use o x86, desde que as interrupções VGA. Mas você ainda não seria capaz de interagir adequadamente com a GPU e ficaria preso em baixa resolução.

Entendo que você deseja construir tudo sozinho e não usar um mecanismo ou algo assim. Mas criar sua própria API gráfica criaria apenas inconveniência para o usuário.

UDXS
fonte
0

Você pode escrever seu próprio driver e API, não há nada para impedi-lo, exceto sua capacidade e níveis de conhecimento. Se nada mais seria uma boa experiência de aprendizado, o verdadeiro problema é que, sem ter muita experiência gráfica anterior, mesmo que você seja um ótimo programador, provavelmente ficará sem saber o que precisa fazer ... ou até para começar.

No entanto, a interface que você cria será mais fácil de usar e mais estável para você do que algo atualizado constantemente nas suas costas. Portanto, é um pouco surpreendente para mim que mais pessoas não sigam esse caminho, mas a realidade é que poucas pessoas têm perspicácia técnica e ninguém quer pagar alguém por anos a fio para aprender como fazer tudo isso, e possivelmente eles saem da empresa e os deixam em apuros. O lado bom da padronização é que isso torna os funcionários muito mais dispendiosos e reduz os riscos.

Yudrist
fonte