Dois-je vraiment utiliser une API graphique?

22

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?

Rubayet Bijoy
la source
30
CUDA et OpenCL ne sont pas des API graphiques.
Savon
4
Pour "contacter indépendamment le pilote graphique", vous avez toujours besoin d'une API!
Josef
21
Non, vous n'avez pas besoin d'une API pour les graphiques, vous pouvez accéder directement au pilote, cela ne s'arrête même pas là, vous pouvez écrire votre propre pilote pour parler directement au matériel si vous le souhaitez. Mais votre question suivante est beaucoup plus importante: "Dois-je utiliser une API graphique?", Oui, oui, vous devriez.
Kevin
5
Vous vous rendez compte qu'une API est également créée à un moment donné? Le pilote est exposé aux appels externes qu'une API implémente et encapsule dans de jolis appels d'API faciles à utiliser.
Kevin
3
Il n'y a pas de carte graphique (ou OS, à ce stade) qui ne prend pas en charge OpenGL. Il fonctionne littéralement sur tout, donc si la seule raison pour laquelle vous ne voulez pas l'utiliser est pour la "compatibilité", c'est une préoccupation complètement sans fondement.
Sandalfoot

Réponses:

39

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.

Sean Middleditch
la source
Bravo, bon ajout à la discussion. Vous apprenez quelque chose de nouveau chaque jour.
Ingénieur
1
Qu'est-ce qui restreint votre choix d'écrire un module du noyau pour accéder au matériel? De plus, si vous ciblez une seule carte (celle de votre machine), les problèmes de compatibilité disparaissent; bien que ce soit encore loin d'être une chose banale à faire; mais dans le domaine du réalisable, étant donné les pilotes de rétro-ingénierie; surtout si vous n'avez qu'une portée limitée de ce que vous voulez faire avec la carte.
Joel Bosveld du
1
La signature du pilote sur de nombreux systèmes d'exploitation rend difficile la distribution de votre module. Vous pouvez certainement créer toutes sortes de pilotes de système d'exploitation et de hacks localement, mais vous ne pourrez pas distribuer votre jeu très largement, ce qui, je suppose, est un aspect souhaité car l'OP a demandé de créer un jeu réel, pas inutile démo technologique. : p
Sean Middleditch
27

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.

Ingénieur
la source
11
Pour empiler au profit de l'OP: le rendu logiciel a également des performances nettement inférieures. Bien que cela n'ait pas d'importance en termes de fréquence d'images pour les jeux plus simples, je doute que de nombreux clients apprécieront la réduction de la durée de vie de la batterie dont ils souffrent, car le rendu logiciel maintient leur processeur beaucoup plus actif qu'il n'aurait dû l'être autrement.
Chris Hayes
1
Bon point, @ChrisHayes ... édité pour ajouter. On suppose parfois que de telles choses sont évidentes.
Ingénieur
1
Il semble que votre premier paragraphe indique que techniquement, il n'est pas nécessaire d'utiliser une API. Bien sûr, cela fait gagner énormément de temps au programmeur, peut-être plus d'une personne a à offrir, mais ce n'est pas nécessaire . Comme je m'y attendais, à moins qu'il n'y ait une sorte de vérification cryptographique en cours entre le pilote de la carte graphique et les bibliothèques de logiciels de niveau supérieur.
David Z
5
@DavidZ Avez-vous écrit un pilote? Savez-vous ce que c'est que d'interfacer avec du matériel complexe lorsque vous n'avez même pas les spécifications, quand même les ingénieurs employés par le fabricant de la carte ont mis des mois-hommes pour développer le pilote? Multipliez maintenant cela par le nombre d'architectures que vous devez prendre en charge. Si je dis: «Il est impossible de gravir l'Everest sans équipement», bien sûr, il y a une chance que vous puissiez, mais c'est vraiment une chance si minuscule ... pourquoi quelqu'un argumenterait-il le point?
Ingénieur
1
Demandez à l'OP pourquoi il veut faire valoir ce point ;-) mais surtout après le montage, il est assez clair que c'est ce qu'il veut.
David Z
8

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.

Philipp
la source
6

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 .

pjc50
la source
4

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!

Luaan
la source
4

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.

concept3d
la source
1

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.

Peter - Unban Robert Harvey
la source
1

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).

John
la source
1

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.

Lars Kokemohr
la source
0

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.

UDXS
la source
0

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.

Yudrist
la source