Dois-je vraiment utiliser une API graphique?

Est-il nécessaire d'utiliser des API graphiques pour obtenir une accélération matérielle dans un jeu 3D? Dans quelle mesure est-il possible de s'affranchir des dépendances des API de cartes graphiques comme OpenGL, DirectX , CUDA, OpenCL ou quoi que ce soit d'autre?

Puis-je créer ma propre API graphique ou bibliothèque pour mon jeu? Même si c'est difficile, est-il théoriquement possible que mon application 3D contacte indépendamment le pilote graphique et rende tout sur le GPU?

Je pense que beaucoup de réponses manquent un point important: vous pouvez écrire des applications qui accèdent directement au matériel, mais pas sur les systèmes d'exploitation modernes . Ce n'est pas seulement un problème de temps, mais un problème "vous n'avez pas le choix".

Windows, Linux, OSX, etc. interdisent tous l'accès matériel direct à des applications arbitraires. Ceci est important pour des raisons de sécurité: vous ne voulez pas qu'une application aléatoire puisse lire la mémoire GPU arbitraire pour la même raison que vous ne voulez pas qu'une application aléatoire puisse lire la mémoire système. Des choses comme le framebuffer pour votre compte bancaire ou quoi que ce soit en direct dans la mémoire GPU. Vous voulez que ce truc soit isolé et protégé et que l'accès soit contrôlé par votre système d'exploitation.

Seuls les pilotes peuvent communiquer directement avec la plupart du matériel, et la seule façon de communiquer avec le pilote est via la couche HAL exposée du système d'exploitation et l'interface propriétaire et incompatible de chaque pilote. Cette interface de pilote sera non seulement différente pour chaque fournisseur, mais différera même entre les versions du pilote lui-même, ce qui rend presque impossible de parler directement à l'interface dans une application grand public. Ces couches sont souvent couvertes par des contrôles d'accès qui limitent davantage la possibilité pour une application d'y accéder.

Donc non, votre jeu ne peut pas simplement utiliser directement le matériel, à moins bien sûr que vous ne cibliez que des systèmes d'exploitation non sécurisés comme DOS, et que votre seule option possible pour un jeu sur des systèmes d'exploitation grand public modernes soit de cibler une API publique comme DirectX, OpenGL ou Vulkan.

C'est pratiquement nécessaire, oui. C'est nécessaire car à moins que vous ne vouliez passer des années à écrire ce qui est essentiellement du code de pilote pour la multitude de configurations matérielles différentes, vous devez utiliser une API qui s'unifie avec les pilotes existants écrits par les fournisseurs de GPU pour tous les systèmes d'exploitation et matériels courants.

La seule alternative réaliste est que vous n'utilisez pas l'accélération 3D et que vous optez plutôt pour un rendu logiciel qui, à condition qu'il soit écrit dans quelque chose de vraiment portable comme C, pourra fonctionner sur à peu près n'importe quel système / appareil. C'est bien pour les petits jeux ... quelque chose comme SDL est adapté à cet effet ... il y en a d'autres aussi. Mais cela manque de capacités 3D inhérentes, vous devrez donc les construire vous-même ... ce qui n'est pas une tâche triviale.

Souvenez-vous également que le rendu du processeur est inefficace et souffre de performances médiocres par rapport aux GPU.

Les API comme OpenGL ou DirectX sont partiellement implémentées par le système d'exploitation et partiellement implémentées par le pilote graphique lui-même.

Cela signifie que lorsque vous souhaitez créer votre propre API de bas niveau qui utilise les capacités des GPU modernes, vous devez essentiellement écrire un propre pilote graphique. S'assurer que votre pilote fonctionne avec toutes les cartes graphiques courantes serait tout un défi, surtout parce que les fournisseurs ne sont souvent pas très ouverts avec leurs spécifications.

Démarrez votre PC sous MS-DOS. Ensuite, en utilisant votre copie de l' encyclopédie des programmeurs de jeux PC , vous pouvez écrire directement dans les registres VESA de la carte et dans la mémoire vidéo. J'ai toujours le code que j'ai écrit il y a 20 ans pour le faire et rendre le 3D rudimentaire dans un logiciel.

Alternativement, vous pouvez simplement utiliser DirectX; c'est une couche d'abstraction vraiment mince, et vous permet également d'écrire directement dans des tampons vidéo, puis de les échanger à l'écran.

Il y a aussi l'approche extrême de la construction de votre propre matériel vidéo .

Les autres réponses répondent très bien à votre question principale: techniquement, c'est possible, mais dans la pratique, si votre objectif est d'élargir votre clientèle, vous faites en fait le contraire. Tout en gaspillant une énorme quantité de travail sur la prise en charge des milliers de configurations matérielles et OS différentes que vous devez prendre en charge.

Cependant, cela ne signifie pas que vous devez être à 100% dépendant d'une API particulière. Vous pouvez toujours coder votre propre couche d'abstraction, puis échanger les implémentations plus spécifiques (par exemple une implémentation DirectX, une implémentation OpenGL, ...) dans et hors.

Même alors, cela n'en vaut probablement pas la peine. Choisissez simplement quelque chose qui fonctionne assez bien pour vos besoins et terminez-le. Vous êtes un créateur de jeux indépendants - vous devez vous concentrer sur les choses qui font le jeu, pas sur les minuties. Faites simplement le jeu!

En résumé: Théoriquement, vous pouvez, mais c'est impossible, et vous n'obtiendrez aucun avantage. Les limitations des API sont aujourd'hui devenues de moins en moins quotidiennes, vous avez CUDA et OpenCL et des shaders. Donc, avoir un contrôle total n'est plus un problème.

Explication plus complète:

Répondre à cela est un ennuyeux oui . La vraie question est pourquoi ?

J'imagine à peine pourquoi voudriez-vous faire cela autrement qu'à des fins d'apprentissage. Vous devez savoir qu'à un moment donné, les développeurs avaient la liberté de faire n'importe quoi avec leurs implémentations de rendu CPU, tout le monde avait sa propre API, ils contrôlaient tout dans le "pipeline". Avec l'introduction du pipeline fixe et des GPU, tout le monde est passé.

Avec les GPU, vous obtenez de "meilleures" performances, mais perdez beaucoup de liberté. Les développeurs graphiques s'efforcent de récupérer cette liberté. Par conséquent, plus de pipeline de personnalisation au quotidien. Vous pouvez faire presque n'importe quoi en utilisant CUDA / OpenCL et même des shaders, sans toucher aux pilotes.

Vous voulez parler au matériel. Vous devez utiliser un moyen de parler au matériel. De cette façon, c'est l'interface avec le matériel. C'est ce que sont OpenGL, DirectX, CUDA, OpenCL et tout le reste.

Si vous atteignez un niveau inférieur, vous utilisez simplement une interface de niveau inférieur, mais vous utilisez toujours une interface, une seule qui ne fonctionne pas avec autant de cartes différentes que celle de niveau supérieur.

Pour obtenir l'accélération matérielle 3D sans utiliser une API traditionnelle, vous devez essentiellement écrire votre propre code pour dupliquer les fonctionnalités du pilote graphique. Donc, la meilleure façon d'apprendre à le faire est de regarder le code du pilote graphique.

Pour les cartes NVIDIA, vous devriez regarder le projet open source nouveau . Ils ont une collection d'excellentes ressources ici .

Pour les autres marques de cartes graphiques, vous pouvez trouver des projets et une documentation similaires.

Notez que, comme cela a été mentionné dans d'autres réponses, la plupart des systèmes d'exploitation modernes empêcheront les programmes de l'espace utilisateur d'accéder directement au matériel, vous devrez donc écrire votre code et l'installer en tant que pilote de système d'exploitation. Alternativement, vous pouvez utiliser le système d'exploitation FreeDOS, qui n'a pas de telles restrictions, et devrait vous permettre (en théorie) d'accéder directement au matériel, et vous permettre d'écrire un programme régulier qui rend les graphiques accélérés par le matériel 3D. Notez que, même en exploitant le code d'un pilote graphique open source existant, ce serait une énorme quantité de travail non trivial (et pour autant que je sache, n'a jamais été fait, et pour diverses raisons, pourrait ne pas être réellement techniquement possible).

Se débarrasser de DirectX ou d'OpenGl ne supprimerait pas les dépendances, il en introduirait plus. Les autres réponses contiennent déjà plusieurs bons points pourquoi il n'est peut-être même pas possible de parler directement au matériel graphique (du moins ce n'est pas possible), mais ma première réponse serait: si vous avez en fait écrit une bibliothèque qui résume tous les 3d courants graphiques matériels dans une seule API que vous auriez effectivement réécrit DirectX / OpenGl. Si vous deviez utiliser votre code pour écrire un jeu, vous auriez ajouté votre nouvelle bibliothèque comme nouvelle dépendance, tout comme vous avez maintenant DirectX / OpenGl comme dépendance.

En utilisant DirectX ou OpenGl, vos dépendances disent essentiellement "Ce code dépend d'une bibliothèque pour fournir le code qui explique comment exécuter certaines commandes sur différentes cartes graphiques". Si vous n'aviez pas une telle bibliothèque, vous introduiriez la dépendance de "Ce code dépend du matériel graphique qui se comporte exactement de la même manière que le matériel qui existait lorsque j'ai construit le jeu."

Des abstractions comme OpenGl ou DirectX permettent aux fabricants de matériel de fournir leur propre code (pilotes) qui mène à une base de code commune, de sorte que les jeux sont plus susceptibles de fonctionner sur du matériel qui n'existait même pas au moment de l'écriture du jeu.

Tout d'abord, CUDA et OpenCL ne sont pas des API graphiques. Ce sont des API de calcul.

Le problème avec l'écriture de votre propre API graphique est qu'elle est très complexe. Vous pouvez vous connecter directement au matériel, mais rien ne garantit que s'il fonctionne sur un système avec X CPU, X GPU, X quantité de RAM et X système d'exploitation, il fonctionnera sur un système avec Y CPU, Y GPU, etc. Un bon point est que DirectX fonctionne avec les pilotes en mode noyau. Il est enraciné dans le noyau. De plus, les API graphiques ne sont pas conçues pour prendre en charge les GPU. Les GPU (et leurs pilotes) sont conçus pour les prendre en charge. Donc, vous ne pouvez pratiquement pas créer une API graphique à moins de créer votre propre système d'exploitation et d'utiliser des interruptions VGA fournies par x86. Mais vous ne seriez toujours pas en mesure de vous interfacer correctement avec le GPU et vous seriez bloqué en basse résolution.

Je comprends que vous voulez tout construire vous-même et ne pas utiliser de moteur ou quelque chose du genre. Mais créer votre propre API graphique ne ferait que gêner l'utilisateur.

Vous pouvez écrire votre propre pilote et API, il n'y a rien pour vous arrêter, sauf vos capacités et vos connaissances. Si ce n'est rien d'autre, ce serait une bonne expérience d'apprentissage, le vrai problème est que sans avoir beaucoup d'expérience graphique précédente, même si vous êtes un grand programmeur, vous serez probablement à court de ce que vous devez faire ... ou même pour commencer.

Pourtant, l'interface que vous créez vous-même sera plus facile à utiliser et plus stable pour vous que quelque chose de constamment mis à jour dans votre dos. Il est donc un peu surprenant pour moi que plus de gens ne choisissent pas cette voie, mais la réalité est que peu de gens ont le sens technique et que personne ne veut payer quelqu'un pendant des années pour apprendre à faire tout cela, alors peut-être ils quittent l'entreprise et les laissent tomber. La bonne chose pour eux à propos de la normalisation est qu'elle rend les employés beaucoup plus consommables et réduit les risques.