Le déverrouillage du débit d'images dans XNA / MonoGame me dira-t-il l'efficacité de mon code?

12

J'ai déverrouillé le framerate dans MonoGame via:

this.graphics.SynchronizeWithVerticalRetrace = false;
base.IsFixedTimeStep = false;

Et en l'utilisant comme base pour évaluer l'efficacité de la mise à jour et du dessin dans le jeu.

À une résolution de 240 x 160, rien n'étant dessiné ou mis à jour sauf un compteur de trames, j'obtiens une valeur FPS de 9 000 à 11 000 FPS.

Si j'ajoute tout mon code, il descend à environ 1100 FPS.

Est-ce une bonne indication que mon code ralentit considérablement le GPU (10x), et devrais-je m'inquiéter? Le jeu va tourner à 60 FPS, donc je suis encore assez loin de cela, mais à quel moment de la fréquence d'images déverrouillée dois-je m'inquiéter?

GPU: AMD FirePro W5000 (FireGL V)

monogame frame-rate

— tester
source

1

En guise de remarque: dans votre chemin de développement, je vous suggère de conserver votre FPS cible dans le débogage ainsi que dans la version; quelque chose pourrait bien fonctionner en version mais pourrait être lent comme l'enfer dans le débogage, ce qui n'est vraiment pas utile :)

— Vaillancourt

Pas vraiment. D'autres réponses répondent bien à cela, mais le point principal est que la plupart des tâches lourdes seront effectuées par votre carte graphique en utilisant l'accélération matérielle. À moins que vous ne travailliez dans le même fil que les graphiques (vous ne devriez pas l'être), il n'y a aucune raison pour que FPS soit affecté par votre code - dans des limites raisonnables - du tout.

— Dan Pantry

30

Seulement grossièrement.

Premièrement, le FPS n'est pas une mesure linéaire . La différence entre 11k FPS et 9k est extrêmement faible (0,0000201 secondes par image). Mais la différence entre 60 et 2060 FPS (un delta de 2k FPS, le même qui existe entre 11k et 9k) est de 0,0161 seconde ... beaucoup plus grande. Il peut donc être dangereux en tant que mesure de performance simplement parce que de grandes différences peuvent ou non être si mauvaises.

Utiliser le temps par image à la place est un peu plus facile à raisonner, mais même dans ce cas, il s'agit toujours d'une vue très large de la situation. Il vous indique simplement combien de secondes une image du jeu prend. Il ne vous dit pas pourquoi , sauf si vous observez une augmentation importante de la durée d'image immédiatement après l'ajout ou l'activation d'une fonctionnalité particulière.

Cela peut être un baromètre de base pour décider qu'il est temps de faire un profilage plus approfondi. Il est particulièrement mauvais d'utiliser FPS pour déterminer si vous êtes lié au CPU ou au GPU; Le profilage GPU n'est pas aussi simple que de mesurer le temps sur le processeur (qui est probablement le moment et le code de calcul FPS).

Quant au moment où vous devriez vous inquiéter ... eh bien, vous avez dit vous-même que le jeu visait 60 FPS. Si vous commencez à plonger près ou en dessous, vous devrez probablement commencer à réfléchir plus attentivement à vos problèmes de performances. Jusque-là, je me concentrerais sur le fonctionnement de tout, puis je m'inquiéterais de le rendre rapide .

6

+1 pour la dernière phrase. L'optimisation prématurée des performances est, à mon avis, une assez mauvaise pratique (en parlant d'expérience).

— sirdank

1

c2.com/cgi/wiki?PrematureOptimization - Lecture recommandée sur le sujet

— Machinarius

Pas toujours, si vous avez une machine haut de gamme et qu'elle atteint environ 80 FPS, alors ce serait assez bien sur votre machine, mais si vous vouliez cibler des ordinateurs bas de gamme, ils ne pourraient obtenir que 15 FPS, Idéalement, ce serait mieux pour effectuer vos tests sur une machine avec les spécifications minimales que vous souhaitez cibler, mais à défaut, l'optimiser pour votre machine peut également l'optimiser pour la leur. Bien sûr, s'il s'exécute assez rapidement sur vos machines bas de gamme, il n'y a aucune raison de faire des efforts supplémentaires pour optimiser davantage, en particulier au risque de bugs accrus.

— Programmdude

5

Je ne vois pas pourquoi tu ne pouvais pas l'utiliser! Gardez à l'esprit que vous devrez peut-être coder différemment pour tenir compte des différences entre l'horodatage fixe / variable, donc si vous prévoyez de le corriger lors de la publication, vous devrez effectuer des ajustements. Voir cet article: http://rbwhitaker.wikidot.com/time-steps

Est-ce une bonne indication que mon code ralentit considérablement le GPU

Peut-être aussi le CPU. Je recommande d'exécuter périodiquement le profileur intégré de Visual Studio (ou chaque fois que vous voyez une grande baisse de fréquence d'images) pour trouver des points chauds dans votre code.

dois-je m'inquiéter?

Cela dépend évidemment du matériel que vous ciblez. Vous devrez tester votre code par rapport aux machines à exigences minimales les plus basses que vous êtes prêt à prendre en charge. S'il y en a au moins 60, je ne serais pas trop inquiet.

— tandersen
source