web-dev-qa-db-fra.com

Comment les jeux 3D sont-ils si efficaces?

Il y a quelque chose que je n'ai jamais compris. Comment un grand jeu PC comme GTA IV peut-il utiliser 50% de mon processeur et fonctionner à 60 images par seconde alors qu'une démonstration DX d'une théière rotative à 60 images par seconde utilise 30%?

performanceopengldirect3d
188
jmasterx

En général, c'est parce que

  1. Les jeux sont optimaux quant à ce dont ils ont besoin pour rendre, et
  2. Ils profitent particulièrement de votre matériel.

Par exemple, une optimisation facile que vous pouvez faire implique de ne pas réellement essayer de dessiner des choses qui ne peuvent pas être vues. Considérez une scène complexe comme un paysage urbain de Grand Theft Auto IV. Le moteur de rendu ne rend pas réellement tous les bâtiments et structures. Au lieu de cela, il rend uniquement ce que la caméra peut voir. Si vous pouviez voler à l'arrière de ces mêmes bâtiments, face à la caméra d'origine, vous verriez une structure Shell creusée à moitié construite. Chaque point que la caméra ne peut pas voir n'est pas rendu - puisque vous ne pouvez pas le voir, il n'est pas nécessaire d'essayer de vous le montrer.

De plus, des instructions optimisées et des techniques spéciales existent lorsque vous développez avec un ensemble particulier de matériel, pour permettre des accélérations encore meilleures.

L'autre partie de votre question est pourquoi une démo utilise autant de CPU:

... alors qu'une démonstration DX d'une théière rotative à 60 ips utilise un énorme 30%?

Il est courant que les démos d'API graphiques (comme dxdemo) reviennent à ce qu'on appelle un logiciel de rend lorsque votre matériel ne prend pas en charge toutes les fonctionnalités nécessaires pour montrer un joli exemple. Ces fonctionnalités peuvent inclure des éléments tels que les ombres, la réflexion, le lancer de rayons, la physique, etc.

Cela imite la fonction d'un périphérique matériel entièrement complet qui est peu susceptible d'exister, afin de montrer toutes les fonctionnalités de l'API. Mais puisque le matériel n'existe pas réellement, il fonctionne à la place sur votre CPU. C'est beaucoup plus inefficace que de déléguer à une carte graphique - d'où votre utilisation élevée du processeur.

69
John Feminella

Patience, compétence technique et endurance.

Le premier point est qu'une DX Demo est principalement une aide à l'enseignement, donc c'est fait pour plus de clarté et non pour la vitesse d'exécution.

C'est un sujet assez important à condenser, mais le développement de jeux consiste principalement à comprendre vos données et vos chemins d'exécution à un degré presque pathologique.

  1. Votre code est conçu autour de deux choses - vos données et votre matériel cible.
  2. Le code le plus rapide est le code qui n'est jamais exécuté - triez vos données en lots et ne faites que des opérations coûteuses sur les données dont vous avez besoin
  3. La façon dont vous stockez vos données est essentielle - visez un accès contigu qui vous permet de traiter par lots à grande vitesse.
  4. Parellisez tout ce que vous pouvez
  5. Les processeurs modernes sont rapides, modernes RAM est très lent. Les échecs de cache sont mortels.
  6. Poussez autant que possible vers le GPU - il a une mémoire locale rapide, il peut donc parcourir les données, mais vous devez l'aider en organisant correctement vos données.
  7. Évitez de faire beaucoup de commutateurs de rendu (encore une fois, regroupez des données de vertex similaires) car cela provoque le blocage du GPU
  8. Accélérez vos textures et assurez-vous qu'elles sont deux puissances - cela améliore les performances du cache de texture sur le GPU.
  9. Utilisez autant de détails que possible - versions basse/moyenne/haute des modèles 3D et basculez en fonction de la distance par rapport au lecteur de caméra - inutile de rendre une version haute résolution si elle ne fait que 5 pixels à l'écran.
95
zebrabox

Les jeux 3D sont parfaits pour tromper vos yeux. Par exemple, il existe une technique appelée occlusion ambiante de l'espace d'écran (SSAO) qui donnera une sensation plus réaliste en observant les parties d'une scène qui sont proches des discontinuités de surface. Si vous regardez les coins de votre mur, vous verrez qu'ils apparaissent légèrement plus foncés que les centres dans la plupart des cas.

Le même effet peut être obtenu en utilisant la radiosité, qui est basée sur une simulation assez précise. La radiosité prendra également en compte plus d'effets des lumières rebondissantes, etc., mais elle est coûteuse en termes de calcul - c'est une technique de lancer de rayons.

Ce n'est qu'un exemple. Il existe des centaines d'algorithmes pour l'infographie en temps réel et ils sont essentiellement basés sur de bonnes approximations et font généralement beaucoup d'hypothèses. Par exemple, le tri spatial doit être choisi très soigneusement en fonction de la vitesse, de la position typique de la caméra ainsi que de la quantité de changements dans la géométrie de la scène.

Ces "optimisations" sont énormes - vous pouvez implémenter un algorithme efficacement et le faire fonctionner 10 fois plus rapidement, mais le choix d'un algorithme intelligent qui produit un résultat similaire ("tricherie") peut vous faire passer de O ( N ^ 4) à O (log (N)).

L'optimisation de l'implémentation réelle rend les jeux encore plus efficaces, mais ce n'est qu'une optimisation linéaire.

39
mnemosyn

Eeeeek!

Je sais que cette question est ancienne, mais c'est excitant que personne n'ait mentionné VSync !!! ???

Vous avez comparé l'utilisation CPU du jeu à 60fps à l'utilisation CPU de la démo de la théière à 60fps.

N'est-il pas évident que les deux tournent (plus ou moins) à exactement 60 images par seconde? Cela mène à la réponse ...

Les deux applications fonctionnent avec vsync activé! Cela signifie (abaissé) que la fréquence d'images de rendu est verrouillée sur "l'intervalle de blanc vertical" de votre moniteur. Le matériel graphique (et/ou le pilote) ne sera rendu qu'au maximum. 60fps. 60fps = 60Hz (Hz = par seconde) taux de rafraîchissement. Donc, vous utilisez probablement un CRT assez ancien et vacillant ou un écran LCD commun. Sur un CRT fonctionnant à 100 Hz, vous verrez probablement des fréquences d'images allant jusqu'à 100 Hz. VSync s'applique également de la même manière que = LCD s'affiche (ils ont généralement un taux de rafraîchissement de 60 Hz).

Ainsi, la démo de la théière peut en fait fonctionner beaucoup plus efficacement! S'il utilise 30% du temps CPU (comparé à 50% du temps CPU pour GTA IV), alors il utilise probablement moins de temps CPU à chaque trame, et attend juste plus longtemps le prochain intervalle vertical vide. Pour comparer les deux applications, vous devez désactiver vsync et mesurer à nouveau (vous mesurerez des fps beaucoup plus élevés pour les deux applications).

Parfois, il est possible de désactiver vsync (la plupart des jeux ont une option dans ses paramètres). Parfois, vous verrez des "artefacts déchirants" lorsque vsync est désactivé.

Vous pouvez trouver des détails à ce sujet et pourquoi il est utilisé sur wikipedia: http://en.wikipedia.org/wiki/Vsync

31
Frunsi

Alors que de nombreuses réponses ici fournissent d'excellentes indications de comment je vais plutôt répondre à la question plus simple de pourquoi

Peut-être le meilleur exemple (certainement l'un des plus connus) est le logiciel Id. Ils ont réalisé très tôt, à l'époque de commandant Keen (bien avant la 3D) que trouver un moyen intelligent de réaliser quelque chose1, même s'il s'appuyait sur du matériel moderne (dans ce cas une carte graphique EGA!) qui était graphiquement supérieur à la concurrence pour que votre jeu se démarque. C'était vrai, mais ils ont en outre réalisé que, plutôt que d'avoir à proposer de nouveaux jeux et contenus eux-mêmes, ils pourraient concéder des licences sur la technologie, obtenant ainsi des revenus des autres tout en étant en mesure de développer la prochaine génération de moteur et ainsi de sauter à nouveau dans la compétition. .

Les capacités de ces programmeurs (couplées à un sens des affaires) sont ce qui les a rendus riches.

Cela dit, ce n'est pas nécessairement l'argent qui motive de telles personnes. C'est probablement autant le désir de réaliser, d'accomplir. L'argent qu'ils ont gagné au début signifie simplement qu'ils ont maintenant du temps à consacrer à ce qu'ils aiment. Et tandis que beaucoup ont intérêts extérieurs presque tous programment encore et essaient de trouver des moyens de faire mieux que la dernière itération.

En termes simples, la personne qui a écrit la démonstration de la théière a probablement eu un ou plusieurs des problèmes suivants:

  • moins de temps
  • moins de ressources
  • moins de récompense
  • moins de concurrence interne et externe
  • objectifs moindres
  • moins de talent

Le dernier peut sembler dur2 mais il est clair qu'il y en a qui sont meilleurs que d'autres, les courbes en cloche ont parfois des extrémités extrêmes et elles ont tendance à être attirées par les extrémités extrêmes correspondantes de ce qui est fait avec cette compétence.

Les objectifs moins importants sont probablement la principale raison. La cible de la démo de la théière était juste cela, une démo. Mais pas une démonstration des compétences des programmeurs 3. Ce serait une démo d'une petite facette d'un (gros) OS, dans ce cas le rendu DX.

Pour ceux qui regardent la démo, cela ne l'intéresserait pas, il utilise beaucoup plus de CPU que requis tant qu'il semble assez bon. Il n'y aurait aucune incitation à éliminer les déchets lorsqu'il n'y aurait pas de bénéficiaire. En comparaison, un jeu aimerait avoir des cycles de rechange pour une meilleure IA, un meilleur son, plus de polygones, plus d'effets.

  1. dans ce cas, le défilement en douceur sur le matériel PC
  2. Probablement plus que moi, nous sommes donc clairs à ce sujet
  3. à proprement parler, cela aurait également été une démonstration pour son manager, mais là encore, le lecteur serait le temps et/ou la qualité visuelle.
25
ShuggyCoUk

Pour plusieurs raisons

  • Les moteurs de jeux 3D sont hautement optimisés
  • la plupart du travail est effectué par votre adaptateur graphique
  • 50% Hm, laissez-moi deviner que vous avez un double cœur et qu'un seul cœur est utilisé ;-)

EDIT: Pour donner quelques chiffres

2,8 Ghz Athlon-64 avec GPU NV-6800. Les résultats sont:

  • Processeur: 72,78 Mflops
  • GPU: 2440,32 Mflops
17
stacker

Parfois, une scène peut avoir plus de choses qu'il n'y paraît. Par exemple, une théière tournante avec des milliers de sommets, un mappage d'environnement, un mappage de relief et d'autres pixel shaders complexes, tous rendus simultanément, représente un tas de traitements. Souvent, ces démos de théières sont simplement destinées à montrer une sorte d'effet spécial. Ils peuvent également ne pas toujours faire le meilleur usage du GPU lorsque les performances absolues ne sont pas l'objectif.

Dans un jeu, vous pouvez voir des effets similaires, mais ils sont généralement effectués de manière compromise dans le but de maximiser la fréquence d'images. Ces optimisations s'étendent à tout ce que vous voyez dans le jeu. Le problème devient: "Comment pouvons-nous créer la scène la plus spectaculaire et réaliste avec le moins de puissance de traitement?" C'est ce qui fait des programmeurs de jeux l'un des meilleurs optimiseurs du marché.

8
Steve Wortham
  1. Gestion de scène. kd-trees, abattage frustrum, bsps, boîtes de délimitation hiérarchiques, ensembles de visibilité partielle.
  2. LOD. Changer les versions de détail inférieures pour remplacer les objets éloignés.
  3. Imposteurs. Comme LOD mais pas même un objet juste une image ou un "panneau d'affichage".
  4. SIMD.
  5. Gestion de mémoire personnalisée. Mémoire alignée, moins de fragmentation.
  6. Structures de données personnalisées (c.-à-d. Pas de STL, modèles relativement minimes).
  7. Assemblage par endroits, principalement pour SIMD.
4
Charles Eli Cheese

D'après toutes les réponses qualifiées et bonnes données, celle qui importe est toujours manquante: le compteur d'utilisation du processeur de Windows n'est pas très fiable. Je suppose que cette simple démonstration de théière appelle simplement la fonction de rendu dans sa boucle inactive, bloquant le swap de tampon.

Désormais, le compteur d'utilisation du processeur Windows examine uniquement le temps processeur consacré à chaque processus, mais pas la façon dont ce temps processeur est utilisé. Essayez d'ajouter un

Sleep(0);

juste après le retour de la fonction de rendu, et comparez.

4
datenwolf

De plus, il existe de nombreuses astuces d'un point de vue artistique pour économiser la puissance de calcul. Dans de nombreux jeux, en particulier les plus anciens, les ombres sont précalculées et "cuites" directement dans les textures de la carte. Plusieurs fois, les artistes ont essayé d'utiliser des plans (deux triangles) pour représenter des choses comme des arbres et des effets spéciaux alors que cela ressemblait à peu près au même. Le brouillard dans les jeux est un moyen facile d'éviter de rendre des objets éloignés, et souvent, les jeux ont plusieurs résolutions de chaque objet pour des vues lointaines, moyennes et proches.

3
erjiang

Regardez la réponse sur vsync; c'est pourquoi ils fonctionnent à la même fréquence d'images.

Deuxièmement, le CPU manque de leader dans un match. Une explication simplifiée est que la boucle de jeu principale n'est qu'une boucle infinie:

while(1) { 
  update();
  render();
}

Même si votre jeu (ou dans ce cas, la théière) ne fait pas grand-chose, vous mangez toujours du CPU dans votre boucle.

Le CPU de 50% dans GTA est "plus productif" que le 30% dans la démo, car il est plus que probable qu'il ne fait pas grand-chose du tout; mais le GTA met à jour des tonnes de détails. Même l'ajout d'un "Sleep (10)" à la démo réduira probablement son CPU d'une tonne.

Regardez enfin l'utilisation du GPU. La démo prend probablement <1% sur une carte vidéo moderne tandis que la GTA prendra probablement la majorité pendant le jeu.

En bref, vos repères et mesures ne sont pas précis.

1
user697111

Le cœur de toute réponse devrait être le suivant: les transformations effectuées par les moteurs 3D sont principalement spécifiées dans des ajouts et des multiplications (algèbre linéaire) (pas de branches ou de sauts), les opérations de dessin d'une seule image sont souvent spécifiées de manière à ce que plusieurs ces tâches d'add-mul peuvent être effectuées en parallèle. Les cœurs GPU sont de très bons add-mul, et ils ont des dizaines ou des centaines de cœurs add-mull.

Le processeur se retrouve à faire des choses simples - comme l'IA et d'autres logiques de jeu.

1
Hassan Syed

Comment un grand jeu PC comme GTA IV peut-il utiliser 50% de mon processeur et fonctionner à 60 images par seconde alors qu'une démonstration DX d'une théière rotative à 60 images par seconde utilise 30%?

Bien que GTA soit probablement plus efficace que la démo DX, la mesure de l'efficacité du processeur de cette manière est essentiellement cassée. L'efficacité pourrait être définie, par exemple par la quantité de travail que vous faites par temps donné. Un contre-exemple simple: générer un thread par CPU logique et laisser une simple boucle infinie s'exécuter dessus. Vous obtiendrez une utilisation du processeur de 100%, mais ce n'est pas efficace, car aucun travail utile n'est effectué.

Cela conduit également à une réponse: comment un jeu peut-il être efficace? Lors de la programmation de "grands grands jeux", un effort énorme est consacré à l'optimisation du jeu sous tous ses aspects (qui comprend aujourd'hui également généralement des optimisations multicœurs). Quant à la démo DX, son but n'est pas de courir vite, mais plutôt de démontrer des concepts.

1
Suma

Je pense que vous devriez jeter un œil à l'utilisation du GPU plutôt qu'au CPU ... Je parie que la carte graphique est beaucoup plus occupée dans GTA IV que dans l'exemple Teapot (il devrait être pratiquement inactif).

Vous pourriez peut-être utiliser quelque chose comme ce moniteur pour vérifier que:

http://downloads.guru3d.com/Rivatuner-GPU-Monitor-Vista-Sidebar-Gadget-download-2185.html

Le framerate est également quelque chose à considérer, peut-être que l'échantillon de théière fonctionne à pleine vitesse (peut-être 1000fps) et la plupart des jeux sont limités à la fréquence de rafraîchissement du moniteur (environ 60fps).

1
fortran

La démo de la théière DX n'utilise pas 30% du CPU pour faire un travail utile. Il est occupé à attendre car il n'a rien d'autre à faire.

1
Chuck Walbourn

D'après ce que je sais de la série Unreal, certaines conventions sont brisées comme l'encapsulation. Le code est compilé en bytecode ou directement en code machine selon le jeu. De plus, les objets sont rendus et empaquetés sous la forme de maillages et des choses telles que les textures, l'éclairage et les ombres sont précalculées alors qu'en pure animation 3D l'exige en temps réel. Lorsque le jeu est en cours d'exécution, il existe également des optimisations telles que le rendu uniquement les parties visibles d'un objet et l'affichage des détails de texture uniquement en gros plan. Enfin, il est probable que les jeux vidéo sont conçus pour tirer le meilleur parti d'une plateforme à un moment donné (ex: Intelx86 MMX/SSE, DirectX, ...).

0
James P.

Je pense qu'il manque une partie importante de la réponse ici. La plupart des réponses vous disent de "Connaître vos données". Le fait est que vous devez également, de la même manière et avec le même degré d'importance, connaître:

  • CPU (horloge et caches)
  • Mémoire (fréquence et latence)
  • Disque dur (en termes de vitesse et de temps de recherche)
  • GPU (#cores, horloge et sa mémoire/caches)
  • Interfaces: contrôleurs Sata, révisions PCI, etc.

MAIS , en plus de cela, avec les ordinateurs modernes actuels, vous ne pourrez jamais lire une vraie vidéo 1080p à >> 30ftp (une seule image 1080p en 64 bits prendrait 15 000 Ko/14,9 Mo). La raison en est à cause de l'échantillonnage/précision. Un jeu vidéo n'utiliserait jamais une double précision (64 bits) pour les pixels, les images, les données, etc ..., mais utiliserait plutôt une précision personnalisée inférieure (~ 4-8 bits) et parfois moins de précision redimensionnée avec des techniques d'interpolation pour permettre un calcul raisonnable temps.

Il existe également d'autres techniques telles que l'écrêtage des données (à la fois avec la norme OpenGL et la mise en œuvre logicielle), la compression des données, etc. Cependant, un bon programmeur peut obtenir un facteur 10-20x, à moins que votre problème ne soit entièrement optimisé et complètement parallélisable (en particulier la tâche parallélisable).

Par expérience, je peux vous dire que l'optimisation est comme une courbe exponentielle. Pour atteindre des performances optimales, le temps requis peut être extrêmement important.

Donc, pour revenir à la théière, vous devriez voir comment la géométrie est représentée, échantillonnée et avec quelle précision Vs voit dans GTA 5, en termes de géométrie/textures et surtout, les détails (précision, échantillonnage, etc.)

0
Maiss