Pourquoi avons-nous des cadres graphiques comme OpenGL et DirectX, alors que les jeux peuvent simplement dessiner des pixels directement?


16

Les jeux et autres applications graphiques intensives utilisent des frameworks comme OpenGL et DirectX. Ils nécessitent également des fonctionnalités telles que pixel shader et DX12.

Mais pourquoi aurions-nous besoin de tous ces cadres et fonctionnalités GPU alors que nous pourrions tout dessiner pixel par pixel?

Tout d'abord, le jeu devrait être compilé de manière à être dessiné pixel par pixel. Cela rendra probablement le jeu exécutable, mais sera-t-il plus rapide et fonctionnera-t-il sur n'importe quel GPU couleur 32 bits (même les anciens)?

Je sais que les premiers jeux 3D ont été dessinés pixel par pixel, mais pourquoi ne le font-ils pas maintenant?


En général, faire une opération sur beaucoup de choses est plus efficace et plus facile à penser que de le faire sur chaque chose individuellement.
user541686

2
Parce que chaque jeu devrait être réécrit pour chaque carte graphique. À moins qu'ils n'utilisent pas la carte graphique, mais ils seraient lents.
user253751

Je pense que les sociétés de GPU doivent créer leurs propres pilotes DirectX
Suici Doga

1
"Mais pourquoi aurions-nous besoin de tous ces cadres et fonctionnalités GPU alors que nous pourrions tout dessiner pixel par pixel?" c'est comme ça que ça se faisait dans les bons vieux jours. Wolfenstein 3D, Doom, Duke Nukem 3D, Quake et la plupart des autres jeux de la fin des années 90 utilisaient un rendu logiciel pur (Quake proposait le rendu OpenGL en option).
el.pescado

1
@MatthewRock Vous n'êtes pas utile. Vous pouvez certainement regrouper un système d'exploitation avec un jeu dans un conteneur Docker et distribuer le conteneur. De cette façon, l'utilisateur n'a pas besoin d'installer les dépendances de bibliothèque pour sa distribution.
Navin

Réponses:


23

La vitesse est la raison la plus courante pour laquelle cela n'est pas fait. En fait, vous pouvez faire ce que vous proposez, si vous créez votre propre système d'exploitation, cela va être très lent pour des raisons architecturales. Donc, l'hypothèse que son plus rapide est un peu erronée. Même s'il serait plus rapide, il serait moins efficace en termes de développement (comme 1% d'augmentation de vitesse pour 10 fois le travail).

La copie des données du CPU vers la carte graphique est une opération relativement lente. Moins vous copiez, plus votre vitesse de mise à jour peut être rapide. Donc, idéalement, vous auriez la plupart des données sur votre GPU et ne mettriez à jour que de petits morceaux de données. Il y a un monde de différence entre la copie sur 320x200 pixels par rapport à 1920x1200 ou plus. Le nombre de pixels dont vous avez besoin pour mettre à jour augmente de façon quadratique lorsque les côtés s'agrandissent.

Exemple: il est moins coûteux de dire au GPU de déplacer l'image de 10 pixels vers la droite que de copier manuellement les pixels dans la mémoire vidéo à différents emplacements.

Pourquoi devez-vous passer par une API? Tout simplement parce que ce n'est pas votre système. Le système d'exploitation ne peut pas vous permettre de faire ce que vous voulez pour des raisons de sécurité. Deuxièmement, parce que le système d'exploitation a besoin d'abstraire le matériel, même le système d'exploitation parle au pilote via un système abstrait, une API si vous voulez.

En fait, j'évaluerais la probabilité que votre système soit plus rapide, si vous faisiez tout le travail vous-même, près de zéro. C'est un peu comme comparer le C et l'assemblage. Bien sûr, vous pouvez écrire un assemblage, mais les compilateurs sont assez intelligents de nos jours et optimisent de mieux en mieux tout le temps. Il est difficile d'être meilleur manuellement, même si vous le pouvez, votre productivité sera à la traîne.

PS: Une API ne rend pas impossible de faire cette mise à jour comme le faisaient les anciens jeux. C'est juste inefficace, c'est tout. Pas à cause de l'esprit de l'API mais parce que c'est une période inefficace.

PPS: C'est pourquoi ils déploient Vulkan.


6
See the number of pixels you need to update grows exponetially when the sides grow.Quadratique, je pense.
Cthulhu

"La copie des données du CPU vers la carte graphique est une opération relativement lente." C'est vrai, mais non pertinent. Copier plus de quelques millions de pixels à 60 ips est facilement réalisable sur des liaisons PCI-E même modestes (cela ne nécessiterait que quelques centaines de mégaoctets par seconde.)
Coxy

2
@ pjc50 Ce n'est pas faux, mais ce n'est pas tout à fait vrai. Un GPU est spécialisé pour exécuter un seul programme (généralement un shader) en parallèle sur une grande quantité de données. Vous devez donc effectuer les mêmes opérations sur de nombreuses données pour utiliser réellement la puissance de calcul d'un GPU. Si votre programme ne fonctionne pas, vous feriez mieux d'exécuter le programme sur le CPU.
Nero

2
X22X

1
Vous parlez de copier et de déplacer, mais ce qui est plus important, c'est la génération réelle d'image. Vous devez déterminer quel objet sera visible à quel point, comment il sera éclairé, quels seront les effets de la fumée, etc., etc. Les GPU sont hautement optimisés pour effectuer ces opérations rapidement et en parallèle. Les API facilitent l'expression des opérations courantes.
IMil

15

fonctionne sur n'importe quel GPU couleur 32 bits (même les anciens)?

Un peu d'histoire ici: c'est ainsi que les jeux se faisaient sur PC jusqu'à ce que les accélérateurs graphiques commencent à être disponibles au milieu des années 90. Il fonctionnait en effet sur tout le matériel, car le matériel ne faisait pas grand-chose.

Un accélérateur graphique permet de dessiner des pixels beaucoup plus rapidement qu'un processeur, en utilisant du matériel spécialisé et du parallélisme. L'accélérateur contient un certain nombre de cœurs de processeur. Un PC de bureau aura entre 1 et 8 cœurs selon l'âge. Ma carte graphique GTX970Ti possède 1664 (mille six cent soixante-quatre!) Cœurs. Cela bat évidemment le PC pour la vitesse brute de loin.

Cependant, les accélérateurs ne sont pas standardisés et incluent souvent des astuces d'architecture informatique étranges afin d'atteindre leur vitesse. Afin d'écrire un jeu qui n'est pas personnalisé pour une marque et un modèle spécifiques de la carte, une API doit exister. Et c'est pour cela que DirectX, GL et les langages de shader sont utilisés. En fait, l'écriture de shaders est la chose la plus proche de l'écriture d'un programme qui dessine directement des pixels - c'est juste que la carte exécutera mille copies de ce programme pour vous en parallèle, une par pixel.


L'APU de mon ordinateur portable a 256 noyaux de shader à 686 MHz tandis que ma tablette en a 192.
Suici Doga

Hé, le Titan X contient 5760 cœurs.
Daniel

@Daniel Y a-t-il des jeux où le Titan X passe <30fps à ultra haut. Le Titan X est très puissant
Suici Doga

Ummm, l'un d'entre eux, peut-être: maximumpc.com/10-most-graphically-demanding-pc-games
Daniel

@Daniel Les développeurs de ces jeux doivent avoir besoin d'environ 2 à 4 cartes Titan X :)
Suici Doga

14

Juste pour ajouter à la réponse de joojaa , les choses sont toujours dessinées pixel par pixel. Vous générez simplement les pixels à l'aide d'un vertex shader / assembleur / rasterizer, puis les texturez et les allumez à l'aide d'un fragment shader. Tout cela a été fait dans les logiciels dans les années 90 lorsque votre carte vidéo n'était pas beaucoup plus qu'un blitter et un tampon d'image, mais c'était lent comme l'enfer. D'où l'invention des GPU modernes.

Les calculs de dessin qui se produisent sont essentiellement les mêmes qu'à l'époque Doom, mais maintenant ils fonctionnent sur des centaines / milliers d'ALU shader plutôt que sur une poignée de cœurs CPU. Les API se mappent essentiellement sur le même ensemble d'instructions GPU en arrière-plan. Ils sont juste là pour vous empêcher d'avoir à écrire une tonne d'assemblage GPU noueux sur plusieurs plates-formes de fournisseurs.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.