¿Por qué usamos CPU para trazado de rayos en lugar de GPU?


Después de hacer algunas investigaciones sobre rasterización y trazado de rayos. He descubierto que no hay mucha información sobre cómo funcionan las CPU para el trazado de rayos disponible en Internet. Me encontré con un artículo sobre Pixar y cómo pre-renderizaron Cars 2 en la CPU. Esto les llevó 11.5 horas por fotograma. ¿Una GPU no habría renderizado esto más rápido con la misma imagen calidad? http://gizmodo.com/5813587/12500-cpu-cores-were-required-to-render-cars-2 https://www.engadget.com/2014/10/18/disney-big-hero-6 / http://www.firstshowing.net/2009/michael-bay-presents-transformers-2-facts-and-figures / Aclamaciones, Sam

Author: oodle600, 2016-06-25

1 answers

Soy uno de los arquitectos de software de renderizado en un gran estudio de VFX y largometrajes animados con un renderizador propietario (no Pixar, aunque una vez fui el arquitecto de software de renderizado allí también, hace mucho, mucho tiempo).

Casi todo el renderizado de alta calidad para películas (en todos los estudios grandes, con todos los renderizadores principales) es solo CPU. Hay un montón de razones por las que este es el caso. En ningún orden en particular, algunos de los realmente convincentes para darle el sabor de la cuestiones:

  • Las GPU solo van rápido cuando todo está en la memoria. Las tarjetas GPU más grandes tienen, qué, 12 GB más o menos, y tiene que contener todo. Bueno, rutinariamente renderizamos escenas con 30 GB de geometría y esa referencia de 1 TB o más de textura. No se puede cargar eso en la memoria de la GPU, es literalmente dos órdenes de magnitud demasiado grande. Por lo tanto, las GPU simplemente no pueden lidiar con nuestras escenas más grandes (o incluso promedio). (Con los renderizadores de CPU, podemos paginar cosas desde el disco siempre que lo necesitemos. GPU no son buenos en eso.)

  • No crea en el bombo, el trazado de rayos con GPU no es una victoria obvia sobre la CPU. Las GPU son excelentes para un trabajo altamente coherente (haciendo las mismas cosas con muchos datos a la vez). El trazado de rayos es muy incoherente (cada rayo puede ir en una dirección diferente, intersectar diferentes objetos, sombrear diferentes materiales, acceder a diferentes texturas), por lo que este patrón de acceso degrada el rendimiento de la GPU muy severamente. Es solo muy recientemente que el trazado de rayos GPU podría coincidir con el mejor Código de trazado de rayos basado en CPU, y a pesar de que lo ha superado, no es por mucho, no es suficiente para tirar todo el código antiguo y comenzar de nuevo con código frágil con errores para GPU. Y las escenas más grandes y caras son aquellas en las que las GPU son solo marginalmente más rápidas. Ser mucho más rápido en las escenas fáciles no es realmente importante para nosotros.

  • Si tiene 50 o 100 años hombre de código reforzado en producción en su renderizador basado en CPU, simplemente no lo arroja y comienza de nuevo con el fin de consigue un aumento de velocidad 2x. El esfuerzo de ingeniería de software, la estabilidad, etc., es más importante y un factor de costo mayor.

  • Del mismo modo, si su estudio tiene una inversión en un centro de datos con 20,000 núcleos de CPU, todo en el factor de forma más pequeño y eficiente en energía y calor que pueda, también es una inversión de costo hundido que no solo se desperdicia. Reemplazarlos con nuevas máquinas que contienen GPU de primera línea aumenta enormemente el costo de su granja de renderizado, y son más grandes y producen más calor, por lo que literalmente podría no caber en su edificio.

  • La Ley de Amdahl: El "renderizado" en sí es solo una etapa en la generación de las escenas, y las GPU no ayudan con ello. Digamos que se tarda 1 hora en generar y exportar completamente la escena al renderizador, y 9 horas en "renderizar", y de esas 9 horas, una hora es leer textura, volúmenes y otros datos del disco. Así que del total de 10 horas de cómo el usuario experimenta el renderizado (presione el botón hasta que la imagen final sea listo), 8 horas se acelera potencialmente con GPU. Por lo tanto, incluso si la GPU fuera 10 veces más rápida que la CPU para esa parte, se pasa de 10 horas a 1+1+0.8 = casi 3 horas. Así que 10x GPU speedup solo se traduce en 3x ganancia real. Si la GPU era 1,000,000 x más rápida que la CPU para el trazado de rayos, todavía tiene 1+1+tiny, que es solo una aceleración 5x.

Pero, ¿qué hay de diferente en los juegos? ¿Por qué las GPU son buenas para juegos pero no para películas?

En primer lugar, cuando haces un juego, recuerda que tiene que renderizarse en tiempo real: eso significa que su restricción más importante es la velocidad de fotogramas de 60 Hz (o lo que sea), y sacrifica la calidad o las características cuando sea necesario para lograrlo. En contraste, con el cine, la restricción irrompible está haciendo que el director y el supervisor de efectos visuales estén contentos con la calidad y el aspecto que desean, y el tiempo que tarda en obtenerlo es (hasta cierto punto) secundario.

Además, con un juego, renderizas fotograma tras fotograma tras fotograma, en vivo frente a cada usuario. Pero con el cine, efectivamente se están renderizando UNA VEZ, y lo que se entrega a los cines es un archivo de película so por lo que los espectadores nunca sabrán o se preocuparán si le tomó 10 horas por cuadro, pero se darán cuenta si no se ve bien. Así que de nuevo, hay menos de una penalización colocada en esos renders que toman mucho tiempo, siempre y cuando se vean fabulosos.

Con un juego, realmente no sabes qué marcos vas a renderizar, ya que el jugador puede vagar por todo el mundo, ver desde casi cualquier lugar. No puedes y no deberías tratar de hacerlo todo perfecto, solo quieres que sea lo suficientemente bueno todo el tiempo. Pero para una película, las tomas son todas hechas a mano! Una tremenda cantidad de tiempo humano se dedica a componer, animar, iluminar y componer cada toma, y luego solo necesita renderizarla una vez. Piense en la economía: una vez que 10 días de calendario (y salario) se han dedicado a la iluminación y la composición de la toma justo, la ventaja de renderizarla en una hora (o incluso un minuto) frente a la noche, es bastante pequeño, y no vale la pena ningún sacrificio de calidad o complejidad alcanzable de la imagen.

 64
Author: Larry Gritz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-06-26 00:25:58