¿Desbloquear la velocidad de fotogramas en XNA / MonoGame me dirá qué tan eficiente es mi código?

12

He estado desbloqueando la velocidad de fotogramas en MonoGame a través de:

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

Y usándolo como base de cuán eficiente estoy actualizando y dibujando en el juego.

Con una resolución de 240 x 160 sin dibujar ni actualizar nada excepto un contador de cuadros, obtengo un valor de FPS de 9,000 a 11,000 FPS.

Si agrego todo mi código nuevamente, se reduce a aproximadamente 1,100 FPS.

¿Es esta una buena indicación de que mi código está ralentizando significativamente la GPU (10x), y debería preocuparme? El juego se ejecutará a 60 FPS, así que todavía estoy bastante lejos de eso, pero ¿en qué punto de la velocidad de fotogramas desbloqueada debería preocuparme?

GPU: AMD FirePro W5000 (FireGL V)

monogame frame-rate prueba
fuente
1
Como nota al margen: en su ruta de desarrollo, le sugiero que mantenga su FPS objetivo en depuración y en versión; algo que podría funcionar bien en la liberación, pero podría ser lento como el infierno en la depuración, lo que realmente no es útil :)
Vaillancourt
Realmente no. Otras respuestas responden bien a esto, pero el punto principal es que la mayor parte del trabajo pesado será realizado por su tarjeta gráfica usando aceleración de hardware. A menos que esté trabajando en el mismo hilo que los gráficos (no debería estarlo), entonces no hay ninguna razón para que su código afecte a FPS, dentro de lo razonable, en absoluto.
Dan Pantry

Respuestas:

30

Solo crudamente.

Primero, FPS no es una medida lineal . La diferencia entre 11k FPS y 9k es extremadamente pequeña (0.0000201 segundos por cuadro). Pero la diferencia entre 60 y 2060 FPS (un delta de 2k FPS, lo mismo que existe entre 11k y 9k) es 0.0161 segundos ... mucho más grande. Por lo tanto, puede ser peligroso como una métrica de rendimiento simplemente porque grandes diferencias pueden o no ser tan malas.

En cambio, usar el tiempo por cuadro es un poco más fácil de razonar, pero aun así sigue siendo una visión muy amplia de la situación. Simplemente te dice cuántos segundos toma un fotograma del juego. No le dice por qué , a menos que observe un gran aumento en el tiempo de fotogramas inmediatamente después de agregar o habilitar una función en particular.

Puede ser un barómetro básico para decidir que es hora de hacer un perfil más profundo. Es particularmente malo usar FPS para determinar si está vinculado a la CPU o GPU; La creación de perfiles de GPU no es tan fácil como medir el tiempo en la CPU (que es donde probablemente esté su código de sincronización y cálculo de FPS).

En cuanto a cuándo debería preocuparte ... bueno, dijiste que el juego apuntaba a 60 FPS. Si comienza a sumergirse cerca o debajo de eso, entonces probablemente deba comenzar a pensar más cuidadosamente sobre sus problemas de rendimiento. Hasta entonces, me concentraría en hacer que todo funcione y luego me preocuparía por hacerlo rápido .


fuente
66
+1 para la última oración. La optimización del rendimiento prematuro es, en mi opinión, una práctica bastante mala (hablando por experiencia).
sirdank
1
c2.com/cgi/wiki?PrematureOptimization - Lectura recomendada sobre el tema
Machinarius
No siempre, si tiene una máquina de gama alta y obtiene alrededor de 80 FPS, entonces sería lo suficientemente buena en su máquina, pero si quisiera apuntar a computadoras de gama baja, solo podrían obtener 15 FPS, idealmente, sería lo mejor para hacer sus pruebas en una máquina con las especificaciones mínimas que desea apuntar, pero en su defecto, optimizarla para su máquina también puede optimizarla para las suyas. Por supuesto, si funciona lo suficientemente rápido en sus máquinas de gama baja, entonces no hay razón para gastar un esfuerzo adicional para optimizar aún más, especialmente a riesgo de un aumento de errores.
Programmdude
5

¡No veo por qué no pudiste usarlo! Tenga en cuenta que es posible que tenga que codificar de manera diferente para tener en cuenta las diferencias entre el paso de tiempo fijo / variable, por lo que si planea arreglarlo cuando lo lance, tendrá que hacer ajustes. Ver este artículo: http://rbwhitaker.wikidot.com/time-steps

¿Es esta una buena indicación de que mi código está ralentizando significativamente la GPU?

Podría ser la CPU también. Recomiendo ejecutar periódicamente el generador de perfiles incorporado de Visual Studio (o cada vez que vea una gran caída de la velocidad de fotogramas) para encontrar puntos calientes en su código.

¿Debería Preocuparme?

Eso obviamente depende del hardware al que se dirige. Tendrá que probar su código con las máquinas con los requisitos mínimos más bajos que está dispuesto a admitir. Si funciona al menos 60 allí, entonces no estaría demasiado preocupado.

Tandersen
fuente