unity para online juegos guerra gratis descargar chicas carros aventura performance opengl direct3d

performance - para - juegos en 3d de guerra



¿Cómo son los juegos en 3D tan eficientes? (17)

¿Cómo puede un gran juego para PC como GTA IV usar el 50% de mi CPU y ejecutar a 60 fps, mientras que una demo DX de una Tetera giratoria a 60 fps usa un enorme 30%?

Si bien es probable que GTA sea más eficiente que la demo DX, la medición de la eficiencia de la CPU de esta manera está esencialmente rota. La eficiencia podría definirse, por ejemplo, por la cantidad de trabajo que realiza por cada tiempo dado. Un contraejemplo simple: generar un hilo por CPU lógica y dejar que se ejecute un bucle infinito simple. Obtendrá un uso de CPU del 100%, pero no es eficiente, ya que no se realiza ningún trabajo útil.

Esto también conduce a una respuesta: ¿cómo puede un juego ser eficiente? Cuando se programan "grandes juegos grandes", se dedica un gran esfuerzo a optimizar el juego en todos los aspectos (que actualmente también incluye optimizaciones multinúcleo). En cuanto a la demo de DX, su punto no es rápido, sino que demuestra conceptos.

Hay algo que nunca he entendido. ¿Cómo puede un gran juego para PC como GTA IV usar el 50% de mi CPU y ejecutar a 60 fps, mientras que una demo DX de una Tetera giratoria a 60 fps usa un enorme 30%?

  1. Gestión de escena kd-trees, custing de frustrum, bsps, cajas de límites jerárquicos, conjuntos de visibilidad parcial.
  2. LOD. Cambiar las versiones de menor detalle para sustituir objetos lejanos.
  3. Impostors. Como LOD, pero ni siquiera un objeto es solo una imagen o ''cartelera''.
  4. SIMD.
  5. Administració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.

A veces, una escena puede estar sucediendo 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 procesan simultáneamente equivale a una gran cantidad de procesamiento. Muchas veces estas demostraciones de teteras son simplemente para 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, es posible que vea efectos similares, pero generalmente se realizan de forma 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.

Además, hay muchos muchos trucos desde un punto de vista artístico para ahorrar energía 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 vería casi igual. La niebla en los juegos es una manera fácil de evitar la representación de objetos lejanos y, a menudo, los juegos tienen resoluciones múltiples de cada objeto para vistas lejanas, medias y cercanas.

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

Tal vez podrías 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 ejecuta a toda velocidad (tal vez 1000 fps) y la mayoría de los juegos están limitados a la frecuencia de actualización del monitor (alrededor de 60 fps).

Creo que falta una parte importante de la respuesta aquí. La mayoría de las respuestas te dicen "Conoce tus datos". El hecho es que debe, de la misma manera y con el mismo grado de importancia, 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 sería capaz de reproducir un video real de 1080p a >> 30ftp (una imagen de 1080p en 64bits tomaría 15 000 Ko / 14,9 MB). El motivo es el muestreo / precisión. Un videojuego nunca usaría una doble precisión (64bits) para píxeles, imágenes, datos, etc., sino que usaría una precisión personalizada más baja (~ 4-8 bits) y, a veces, menos escala de precisión con técnicas de interpolación para permitir un cálculo razonable. hora.

También existen otras técnicas como Recortar datos (ambos con el estándar OpenGL y la implementación del software), 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é totalmente optimizado y completamente paralelizable (en particular, la tarea sea 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.

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

Eeeeek!

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

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

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

¡Ambas aplicaciones se ejecutan con vsync habilitado! Esto significa (simplificado) 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 el controlador) solo se mostrarán al máximo. 60 fps. 60 fps = 60 Hz (Hz = por segundo) frecuencia de actualización. Entonces probablemente use un CRT parpadeante bastante antiguo o una pantalla LCD común. En un CRT que se ejecuta a 100Hz probablemente verá tasas de cuadros de hasta 100Hz. VSync también se aplica de forma similar a las pantallas LCD (generalmente tienen una frecuencia de actualización de 60Hz).

Por lo tanto, ¡la demostración de la tetera puede funcionar mucho más eficiente! Si utiliza el 30% del tiempo de CPU (en comparación con el 50% del tiempo de CPU para GTA IV), probablemente use menos tiempo de CPU en cada cuadro, y simplemente espere más tiempo para el próximo intervalo en blanco vertical. Para comparar ambas aplicaciones, debe desactivar 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 de desgarro" cuando vsync está deshabilitado.

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

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

La CPU se queda con hacer cosas simples, como la inteligencia artificial y otra lógica de juego.

La demo de la tetera DX no usa el 30% de la CPU haciendo un trabajo útil. Está ocupado, esperando porque no tiene nada más que hacer.

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

El mismo efecto se puede lograr usando la radiosidad, que se basa en una simulación bastante precisa. La radiosidad también tendrá en cuenta más efectos de luces que se encienden, 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 generalmente hacen suposiciones. Por ejemplo, la clasificación espacial debe elegirse con mucho cuidado dependiendo de 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 : puedes implementar un algoritmo de manera eficiente y hacer que funcione 10 veces más rápido, pero elegir un algoritmo inteligente que produzca un resultado similar ("hacer trampa") puede hacerte pasar de O (N ^ 4) a O ( log (N)).

Optimizar 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.

Mira la respuesta en vsync; es por eso que se están ejecutando a la misma velocidad de cuadro.

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 consume la CPU en su ciclo.

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

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

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

Paciencia, habilidad técnica y resistencia.

El primer punto es que una demostración DX es principalmente una ayuda de 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 entender tus datos y tus caminos 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 de destino.
  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 con los datos que necesita para
  3. La forma de almacenar sus datos es clave: apunte a un acceso contiguo que le permite realizar procesos por lotes a gran velocidad.
  4. Parellise todo lo que pueda
  5. Las CPU modernas son rápidas, la RAM moderna es muy lenta. Las fallas de caché son mortales.
  6. Presiona tanto con la GPU como puedas: tiene una memoria local rápida para que pueda funcionar a través de los datos, pero necesitas ayudarlo organizando tus datos correctamente.
  7. Evite hacer muchos interruptores de renderstate (una vez más lotes de datos de vértices similares) ya que esto hace que la GPU se bloquee
  8. Swizzle sus texturas y asegúrese de que sean potencias de dos, esto mejora el rendimiento de la memoria caché de la GPU.
  9. Utilice los niveles de detalle tanto como sea posible: versiones baja / media / alta de modelos 3D e interruptor según la distancia desde el reproductor de la cámara; sin puntos para renderizar una versión de alta resolución si solo tiene 5 píxeles en la pantalla.

Por algunas razones

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

EDITAR: Para dar algunos números

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

  • CPU: 72.78 Mflops
  • GPU: 2440.32 Mflops

Por lo que sé de la serie Unreal, algunas convenciones se rompen como la encapsulación. El código se compila a bytecode o directamente en código de máquina según el juego. Además, los objetos se representan y empaquetan bajo la forma de mallas y cosas como texturas, iluminación y sombras se calculan previamente, mientras que una animación en 3D pura lo requiere en este momento real. Cuando el juego se está ejecutando realmente también hay algunas optimizaciones, tales como representar solo las partes visibles de un objeto y mostrar los detalles de la textura solo al acercarse. 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, ...).

Por todas las respuestas calificadas y buenas dadas, la que todavía falta: el contador de utilización de CPU de Windows no es muy confiable. Supongo que esta simple demostración de tetera simplemente llama a la función de renderizado en su ciclo inactivo, bloqueando en el intercambio de buffer.

Ahora, el contador de utilización de la 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. Prueba agregar un

Sleep(0);

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

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

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 del 3D), que tenían una forma inteligente de lograr algo 1 , incluso si confiaban en hardware moderno (¡en este caso una tarjeta gráfica EGA!) Que era gráficamente superior a la competencia 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, podían licenciar la tecnología, obteniendo así ingresos de los demás mientras podían desarrollar la próxima generación de motores y, por lo tanto, saltar de nuevo a la competencia. .

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

Dicho esto, no es necesariamente el 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 dedicarse a lo que disfrutan. Y aunque muchos tienen intereses externos, casi todos siguen programando y tratan de encontrar formas de mejorar la última iteración.

En pocas palabras, la persona que escribió la demostración de la tetera probablemente tenía 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

Lo último puede parecer áspero 2, pero es evidente que hay algunos que son mejores que otros, las curvas de campana a veces tienen extremos extremos y tienden a sentirse atraídos por los extremos correspondientes de lo que se hace con esa habilidad.

Los objetivos menores uno probablemente sean la razón principal. El objetivo de la demostración de tetera era solo eso, una demostración. Pero no es una demostración de la habilidad de los programadores 3 . Sería una demostración de una pequeña faceta de un sistema operativo (grande), en este caso, representación DX.

Para aquellos que ven la demostración, no importa que use mucha más CPU de la requerida siempre que se vea lo suficientemente buena. No habría incentivo para eliminar el desperdicio cuando no hubiera un 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 una vez más, el impulso aquí sería el tiempo y / o la calidad visual.

En general, es porque

  1. Los juegos son óptimos en cuanto a lo que necesitan renderizar, y
  2. Toman ventaja especial de su hardware.

Por ejemplo, una optimización fácil que puede hacer no consiste en tratar de dibujar cosas que no se pueden ver. Considere una escena compleja como un paisaje urbano de Grand Theft Auto IV . El procesador no está representando todos los edificios y estructuras. En cambio, está representando solo lo que la cámara puede ver. Si pudieras volar a la parte posterior de esos mismos edificios, de cara a la cámara original, verías una estructura de caparazón ahuecada a medio construir. Cada punto que la cámara no puede ver no aparece, ya que no puede verlo, no hay necesidad de tratar de mostrárselo.

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 tu pregunta es por qué una demo usa tanta CPU:

... mientras que una demo DX de una Tetera giratoria @ 60 fps usa un enorme 30%?

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

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