¿Cómo son los juegos 3D tan eficientes? [cerrado]

Hay algo que nunca he entendido. ¿Cómo puede un gran gran juego de PC como GTA IV usar el 50% de mi CPU y ejecutarse a 60 fps, mientras que una demostración DX de una Tetera rotativa @ 60fps usa un 30%?

En general, es porque

1. Los juegos son óptimos sobre lo que necesitan renderizar, y
2. Aprovechan especialmente su hardware.

Por ejemplo, una optimización fácil que puede hacer implica no tratar de dibujar cosas que no se pueden ver. Considere una escena compleja como un paisaje urbano de Grand Theft Auto IV . El renderizador no está representando todos los edificios y estructuras. En cambio, solo muestra lo que la cámara puede ver. Si pudieras volar hacia la parte trasera de esos mismos edificios, frente a la cámara original, verías una estructura de carcasa hueca a medio construir. Cada punto que la cámara no puede ver no se procesa, ya que no puede verlo, no es necesario que se lo muestre.

Además, existen instrucciones optimizadas y técnicas especiales cuando se desarrolla contra un conjunto particular de hardware, para permitir aceleraciones aún mejores.

La otra parte de su pregunta es por qué una demostración usa tanta CPU:

... mientras que una demostración DX de una tetera giratoria a 60 fps utiliza un enorme 30%?

Es común que las demostraciones de API de gráficos (como dxdemo) recurran a lo que se llama un procesador de software cuando su hardware no admite todas las características necesarias para mostrar un buen ejemplo. Estas características pueden incluir cosas como sombras, reflexión, trazado de rayos, física, etc.

Esto imita la función de un dispositivo de hardware con todas las funciones que es poco probable que exista, para mostrar todas las características de la API. Pero como el hardware en realidad no existe, se ejecuta en su CPU. Eso es mucho más ineficiente que delegar en una tarjeta gráfica, de ahí su alto uso de CPU.

Paciencia, habilidad técnica y resistencia.

El primer punto es que una demostración DX es principalmente una ayuda para la enseñanza, por lo que se hace por claridad, no por velocidad de ejecución.

Es un tema bastante importante para condensar, pero el desarrollo de juegos se trata principalmente de comprender sus datos y sus rutas de ejecución en un grado casi patológico.

1. Su código está diseñado en torno a dos cosas: sus datos y su hardware objetivo.
2. El código más rápido es el código que nunca se ejecuta: clasifique sus datos en lotes y solo realice operaciones costosas en los datos que necesita
3. La forma en que almacena sus datos es clave: el objetivo de un acceso contiguo le permite procesar por lotes a alta velocidad.
4. Parellise todo lo que puedas
5. Las CPU modernas son rápidas, la RAM moderna es muy lenta. Los errores de caché son mortales.
6. Empuje todo lo que pueda a la GPU: tiene memoria local rápida, por lo que puede atravesar los datos, pero debe ayudarlo organizando sus datos correctamente.
7. Evite hacer muchos cambios de renderstate (nuevamente agrupe datos de vértices similares) ya que esto hace que la GPU se detenga
8. Mezcle sus texturas y asegúrese de que sean potencias de dos: esto mejora el rendimiento de la caché de texturas en la GPU.
9. Use los niveles de detalle tanto como pueda - versiones baja / media / alta de modelos 3D y cambie según la distancia desde el reproductor de la cámara - no tiene sentido representar una versión de alta resolución si solo tiene 5 píxeles en la pantalla.

Los juegos en 3D son geniales para engañar a tus ojos. Por ejemplo, hay una técnica llamada oclusión ambiental del espacio de pantalla (SSAO) que dará una sensación más realista al sombrear aquellas partes de una escena que están cerca de las discontinuidades de la superficie. Si observa las esquinas de su pared, verá que aparecen un poco más oscuras que los centros en la mayoría de los casos.

El mismo efecto se puede lograr utilizando la radiosidad, que se basa en una simulación bastante precisa. La radiosidad también tendrá en cuenta más efectos de las luces que rebotan, etc. pero es computacionalmente costosa: es una técnica de trazado de rayos.

Esto es sólo un ejemplo. Hay cientos de algoritmos para gráficos de computadora en tiempo real y se basan esencialmente en buenas aproximaciones y, por lo general, hacen muchas suposiciones. Por ejemplo, la ordenación espacial debe elegirse con mucho cuidado según la velocidad, la posición típica de la cámara y la cantidad de cambios en la geometría de la escena.

Estas 'optimizaciones' son enormes : puede implementar un algoritmo de manera eficiente y hacerlo funcionar 10 veces más rápido, pero elegir un algoritmo inteligente que produzca un resultado similar ("trampa") puede llevarlo de O (N ^ 4) a O ( log (N)).

La optimización de la implementación real es lo que hace que los juegos sean aún más eficientes, pero eso es solo una optimización lineal.

Eeeeek!

Sé que esta pregunta es antigua, pero es emocionante que nadie haya mencionado VSync.

Comparó el uso de CPU del juego a 60 fps con el uso de CPU de la demostración de la tetera a 60 fps.

¿No es evidente que ambos corren (más o menos) a exactamente 60 fps? Eso lleva a la respuesta ...

Ambas aplicaciones se ejecutan con vsync habilitado! Esto significa (tonto) que la velocidad de fotogramas de representación está bloqueada en el "intervalo vertical en blanco" de su monitor. El hardware de gráficos (y / o controlador) solo se representará al máximo. 60 fps. 60fps = 60Hz (Hz = por segundo) frecuencia de actualización. Por lo tanto, probablemente use una CRT parpadeante bastante antigua o una pantalla LCD común. En un CRT que funciona a 100Hz, probablemente verá velocidades de cuadros de hasta 100Hz. VSync también se aplica de manera similar a las pantallas LCD (generalmente tienen una frecuencia de actualización de 60Hz).

Por lo tanto, la demostración de la tetera en realidad puede ser mucho más eficiente. Si usa el 30% del tiempo de CPU (en comparación con el 50% del tiempo de CPU para GTA IV), entonces probablemente use menos tiempo de CPU en cada cuadro, y solo espera más tiempo para el siguiente intervalo vertical en blanco. Para comparar ambas aplicaciones, debe deshabilitar vsync y medir nuevamente (medirá fps mucho más altos para ambas aplicaciones).

A veces está bien deshabilitar vsync (la mayoría de los juegos tienen una opción en su configuración). A veces verá "artefactos desgarrantes" cuando vsync está desactivado.

Puede encontrar detalles y por qué se usa en wikipedia: http://en.wikipedia.org/wiki/Vsync

Si bien muchas respuestas aquí proporcionan excelentes indicaciones de cómo responderé la pregunta más simple de por qué

• GTA4 tomó $ 400 millones de dólares en su primera semana
• Crytech escribió una demostración de gráficos extremadamente impresionante para permitir que nVidia se muestre en una feria comercial. Las impresiones resultantes les ayudaron a crear lo que se convertiría en FarCry.
• Los ingresos y las ganancias operativas de Valve en 2005 se expresaron en 70 y 55 millones de dólares, respectivamente.

Quizás el mejor ejemplo (sin duda uno de los más conocidos) es el software Id. Se dieron cuenta muy temprano, en los días del Comandante Keen (mucho antes de 3D), de encontrar una forma inteligente de lograr algo ¹ , incluso si dependía de hardware moderno (¡en este caso, una tarjeta gráfica EGA!) Que era gráficamente superior a la competencia de que esto haría que tu juego se destaque. Esto era cierto, pero se dieron cuenta de que, en lugar de tener que crear nuevos juegos y contenido ellos mismos, podían licenciar la tecnología, obteniendo así ingresos de otros mientras podían desarrollar la próxima generación de motores y así saltar de nuevo a la competencia. .

Las habilidades de estos programadores (junto con la comprensión empresarial) es lo que los hizo ricos.

Dicho esto, no es necesariamente dinero lo que motiva a esas personas. Es probable que sea tanto el deseo de lograr, de lograr. El dinero que ganaron en los primeros días simplemente significa que ahora tienen tiempo para dedicar a lo que disfrutan. Y aunque muchos tienen intereses externos, casi todos todavía programan e intentan encontrar formas de hacerlo mejor que la última iteración.

En pocas palabras, la persona que escribió la demostración de la tetera probablemente tuvo uno o más de los siguientes problemas:

• menos tiempo
• menos recursos
• menos incentivo de recompensa
• Menos competencia interna y externa
• objetivos menores
• menos talento

El último puede sonar duro ^2, pero claramente hay algunos que son mejores que otros, las curvas de campana a veces tienen extremos y tienden a sentirse atraídos por los extremos extremos correspondientes de lo que se hace con esa habilidad.

Es probable que los objetivos menores sean uno de los motivos principales. El objetivo de la demostración de la tetera era solo eso, una demostración. Pero no es una demostración de la habilidad de los programadores ³ . Sería una demostración de una pequeña faceta de un sistema operativo (grande), en este caso la representación DX.

Para aquellos que vean la demostración, no les importaría que usara mucha más CPU de la requerida siempre que se viera lo suficientemente bien. No habría incentivo para eliminar el desperdicio cuando no hubiera beneficiario. En comparación, a un juego le encantaría tener ciclos de repuesto para una mejor IA, mejor sonido, más polígonos, más efectos.

1. en ese caso, desplazamiento suave en hardware de PC
2. Probablemente más que yo, así que tenemos claro eso
3. estrictamente hablando, también habría sido una demostración para su gerente, pero nuevamente, la unidad aquí sería el tiempo y / o la calidad visual.

Por algunas razones

• Los motores de juego en 3D están altamente optimizados
• la mayor parte del trabajo lo realiza su adaptador de gráficos
• 50% Hm, déjame adivinar que tienes un núcleo dual y solo se usa un núcleo ;-)

EDITAR: para dar pocos números

2.8 Ghz Athlon-64 con GPU NV-6800. Los resultados son:

• CPU: 72.78 Mflops
• GPU: 2440.32 Mflops

A veces, una escena puede tener más de lo que parece. Por ejemplo, una tetera giratoria con miles de vértices, mapeo de entorno, mapeo de relieve y otros sombreadores de píxeles complejos que se representan simultáneamente equivale a una gran cantidad de procesamiento. Muchas veces, estas demostraciones de teteras simplemente pretenden mostrar algún tipo de efecto especial. También es posible que no siempre hagan el mejor uso de la GPU cuando el rendimiento absoluto no es el objetivo.

En un juego puedes ver efectos similares, pero generalmente se realizan de manera comprometida en un esfuerzo por maximizar la velocidad de fotogramas. Estas optimizaciones se extienden a todo lo que ves en el juego. El problema es: "¿Cómo podemos crear la escena más espectacular y realista con la menor cantidad de potencia de procesamiento?" Es lo que hace que los programadores de juegos sean algunos de los mejores optimizadores.

1. Manejo de escena. árboles kd, sacrificio frustrum, bsps, cajas de delimitación jerárquicas, conjuntos de visibilidad parcial.
2. LOD Cambiar versiones de menor detalle para sustituir objetos lejanos.
3. Impostores. Como LOD, pero ni siquiera un objeto, solo una imagen o 'cartelera'.
4. SIMD
5. Gestión de memoria personalizada. Memoria alineada, menos fragmentación.
6. Estructuras de datos personalizadas (es decir, sin STL, plantillas relativamente mínimas).
7. Montaje en lugares, principalmente para SIMD.

Según todas las respuestas calificadas y buenas dadas, aún falta la que importa: el contador de utilización de CPU de Windows no es muy confiable. Supongo que esta simple demostración de tetera solo llama a la función de representación en su bucle inactivo, bloqueando en el intercambio de búfer.

Ahora el contador de utilización de CPU de Windows solo analiza cuánto tiempo de CPU se gasta en cada proceso, pero no cómo se usa este tiempo de CPU. Intenta agregar un

Sleep(0);

justo después de regresar de la función de renderizado y comparar.

Además, hay muchos trucos desde un punto de vista artístico para ahorrar poder computacional. En muchos juegos, especialmente los más antiguos, las sombras se calculan previamente y se "hornean" directamente en las texturas del mapa. Muchas veces, los artistas trataron de usar planos (dos triángulos) para representar cosas como árboles y efectos especiales cuando se veían casi iguales. La niebla en los juegos es una manera fácil de evitar renderizar objetos lejanos y, a menudo, los juegos tendrían múltiples resoluciones de cada objeto para vistas lejanas, medias y cercanas.

El núcleo de cualquier respuesta debería ser este: las transformaciones que realizan los motores 3D se especifican principalmente en adiciones y multiplicaciones (álgebra lineal) (sin ramas ni saltos), las operaciones de dibujar un solo cuadro a menudo se especifican de una manera que Estos trabajos de add-mul se pueden hacer en paralelo. Los núcleos de GPU son muy buenos para agregar add-mul y tienen docenas o cientos de núcleos add-mull.

La CPU se queda haciendo cosas simples, como IA y otra lógica de juego.

¿Cómo puede un gran gran juego de PC como GTA IV usar el 50% de mi CPU y ejecutarse a 60 fps, mientras que una demostración DX de una Tetera rotativa a 60 fps usa un 30%?

Si bien es muy probable que GTA sea más eficiente que la demostración DX, medir la eficiencia de la CPU de esta manera está esencialmente roto. La eficiencia podría definirse, por ejemplo, por la cantidad de trabajo que realiza en un momento dado. Un contraejemplo simple: genera un hilo por una CPU lógica y deja que se ejecute un bucle infinito simple en él. Obtendrá un uso de CPU del 100%, pero no es eficiente, ya que no se realiza ningún trabajo útil.

Esto también lleva a una respuesta: ¿cómo puede un juego ser eficiente? Al programar "grandes juegos grandes", se dedica un gran esfuerzo para optimizar el juego en todos los aspectos (que hoy en día también suele incluir optimizaciones multinúcleo). En cuanto a la demostración DX, su objetivo no es correr rápido, sino demostrar conceptos.

Creo que debería echar un vistazo a la utilización de GPU en lugar de CPU ... Apuesto a que la tarjeta gráfica está mucho más ocupada en GTA IV que en la muestra de Tetera (debería estar prácticamente inactiva).

Tal vez podría usar algo como este monitor para verificar que:

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

Además, la velocidad de fotogramas es algo a considerar, tal vez la muestra de la tetera se esté ejecutando a toda velocidad (quizás 1000 fps) y la mayoría de los juegos están limitados a la frecuencia de actualización del monitor (aproximadamente 60 fps).

Mira la respuesta en vsync; Es por eso que se ejecutan a la misma velocidad de fotogramas.

En segundo lugar, la CPU es líder en un juego. Una explicación simplificada es que el ciclo principal del juego es solo un ciclo infinito:

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

Incluso si su juego (o en este caso, la tetera) no está haciendo mucho, todavía está consumiendo CPU en su bucle.

El 50% de la CPU en GTA es "más productivo" que el 30% en la demostración, ya que lo más probable es que no esté haciendo mucho; pero el GTA está actualizando toneladas de detalles. Incluso agregar un "Sleep (10)" a la demostración probablemente disminuirá su CPU por una tonelada.

Por último, mire el uso de GPU. Es probable que la demo tenga <1% en una tarjeta de video moderna, mientras que GTA probablemente tomará mayoría durante el juego.

En resumen, sus puntos de referencia y mediciones no son precisos.

La demostración de la tetera DX no utiliza el 30% de la CPU para realizar un trabajo útil. Está ocupado esperando porque no tiene nada más que hacer.

Por lo que sé de la serie Unreal, algunas convenciones se rompen como la encapsulación. El código se compila en bytecode o directamente en el código de máquina según el juego. Además, los objetos se procesan y empaquetan bajo la forma de mallas y cosas como texturas, luces y sombras se calculan previamente, mientras que una animación 3D pura requiere esto en tiempo real. Cuando el juego se está ejecutando, también hay algunas optimizaciones, como mostrar solo las partes visibles de un objeto y mostrar detalles de textura solo cuando está cerca. Finalmente, es probable que los videojuegos estén diseñados para obtener lo mejor de una plataforma en un momento dado (por ejemplo: Intelx86 MMX / SSE, DirectX, ...).

Creo que aquí falta una parte importante de la respuesta. La mayoría de las respuestas le dicen "Conozca sus datos". El hecho es que, de la misma manera y con el mismo grado de importancia, también debe conocer su:

• CPU (reloj y cachés)
• Memoria (frecuencia y latencia)
• Disco duro (en términos de velocidad y tiempos de búsqueda)
• GPU (#cores, reloj y su memoria / cachés)
• Interfaces: controladores Sata, revisiones PCI, etc.

PERO , además de eso, con las computadoras modernas actuales, nunca podría reproducir un video real de 1080p a >> 30 pies (una sola imagen de 1080p en 64 bits tomaría 15 000 Ko / 14.9 MB). La razón de esto es por el muestreo / precisión. Un videojuego nunca usaría una precisión doble (64 bits) para píxeles, imágenes, datos, etc., sino que usaría una precisión personalizada más baja (~ 4-8 bits) y, a veces, una precisión menor reescalada con técnicas de interpolación para permitir un cálculo razonable hora.

También hay otras técnicas, como Recortar los datos (tanto con el estándar OpenGL como la implementación de software), la compresión de datos, etc. Tenga en cuenta también que las GPU actuales pueden ser> 300 veces más rápidas que las CPU actuales en términos de capacidad de hardware. Sin embargo, un buen programador puede obtener un factor de 10-20x, a menos que su problema esté completamente optimizado y completamente paralelizable (particularmente la tarea paralelizable).

Por experiencia, puedo decirte que la optimización es como una curva exponencial. Para alcanzar un rendimiento óptimo, el tiempo requerido puede ser increíblemente importante.

Entonces, para volver a la tetera, debe ver cómo se representa, se muestrea la geometría y con qué precisión Vs se ve en GTA 5, en términos de geometría / texturas y lo más importante, los detalles (precisión, muestreo, etc.)