¿Qué es el renderizado de GPU? Renderizado de GPU y sus perspectivas

El renderizado por GPU en , y otros renderizadores que utilizan los recursos de una tarjeta de vídeo en lugar de un procesador, es un verdadero placer al principio. El tiempo de renderizado en comparación, por ejemplo, ha disminuido significativamente, puede evaluar el resultado de los cambios en la escena en tiempo real, puede ver rápidamente cómo se verá todo en los renders finales y mucho más parecerá indicar el indudable dominio de renderizado en una tarjeta de video.

Sin embargo, ¡no todo es tan sencillo! Dejemos de lado las cuestiones de si el renderizado por GPU es adecuado para los requisitos de producción de ciertos tipos de gráficos, la falta de renderizado por GPU de producción completo y todo eso. Imaginemos que tienes un pequeño grupo de 3 visualizadores, principalmente comerciales y ahora has cambiado al renderizado por GPU. Veamos 7 problemas que te esperan:

1. Alto costo de las tarjetas de video, costoso escalamiento de capacidad

La mayoría de las soluciones de GPU dedicadas asumen que agregar tarjetas gráficas es más barato que comprarlas. computadora completa, pero solo al comprar gabinetes y sistemas de servidores especiales para ejecutar una gran cantidad de tarjetas de video. Estas soluciones en sí mismas no son baratas y requieren ciertas habilidades. Pero imaginemos que seguimos el camino de la compra. computadoras estándar e instalando 2-3-4 tarjetas de video en ellos. Compare el costo de una futura actualización del procesador y una actualización de estas 2-3-4 GPU.

2. Poca influencia de las tarjetas de video geniales en todo el sistema.

A diferencia de una actualización de la CPU, que afectará el funcionamiento de todas las aplicaciones, las tarjetas de video solo tendrán el efecto de reducir el tiempo de renderizado. Su presencia no afectará de ninguna manera el funcionamiento del sistema operativo ni de ninguna aplicación de gráficos 3D. Excepto, quizás, en el caso de los juegos. Pero no juegas en la computadora de tu trabajo, ¿verdad?)

En pocas palabras, cuando gastas dinero en una GPU con fines laborales, obtienes beneficios muy limitados y específicos.

3. Generación constante de ruido y calor.

Enfriar casi cualquier tarjeta de video es mucho más ruidoso que enfriar la CPU. Más importante aún, el funcionamiento constante de 2-3 tarjetas de video crea rápidamente una temperatura insoportable en la habitación.

4. Problemas de escala

Si tiene varias máquinas GPU, tarde o temprano surge la cuestión de comprar licencias adicionales y pueden surgir problemas de compatibilidad con tarjetas de video de diferentes fabricantes y diferentes modelos. A medida que se actualiza la flota, es inevitable un choque entre generaciones de tarjetas de video. ¿Recuerda que si un sistema tiene, por ejemplo, una tarjeta de video con 8 GB de memoria y 12 GB, entonces la memoria estará limitada a un valor menor?

Una simple actualización del controlador puede bloquear todo. Las tarjetas de video en cualquier sistema son la principal fuente de congelaciones y fallas. ¡Cualquier problema con la actualización de los controladores, su compatibilidad, errores y otras delicias definitivamente conducirá a problemas en el renderizado! No hace falta decir que no existen tales problemas al renderizar en una CPU.

6. Memoria limitada

Actualmente, la GTX 1080Ti tiene solo 12 GB de memoria, que no se puede aumentar insertando una barra de memoria como en computadoras regulares. Y no cuadra al instalar varias tarjetas. Si, por ejemplo, instala 3 de estas tarjetas, habrá 12 GB disponibles para escenas. Si se excede la memoria disponible en el renderizado, todo simplemente falla. No hay opciones como en la CPU usando un archivo de intercambio, que, aunque ralentiza el renderizado, aún lo hace posible.

7. círculo limitado POR

El renderizado por GPU admite un número limitado de aplicaciones y renderizadores de gráficos, lo que impone sus propias limitaciones.

En conclusión, lo tomaré en cuenta. que a pesar de las desventajas del renderizado por GPU, también tiene indudables ventajas que superan significativamente las desventajas existentes.

¿Cómo crear un renderizador que funcione incluso en la computadora de tu abuela? Inicialmente, nos enfrentamos a una tarea ligeramente diferente: crear un renderizado imparcial para todos los modelos de GPU: NVidia, ATI, Intel.
Aunque la idea de este tipo de renderizado para todas las tarjetas de video ha estado en el aire durante mucho tiempo, no se ha logrado una implementación de alta calidad, especialmente en Direct3D. En nuestro trabajo se nos ocurrió una combinación muy descabellada y más adelante te contamos qué nos llevó a ella y cómo funciona.

Marchevsky explicó muy bien qué es la representación imparcial, es decir, la representación sin suposiciones, en una serie de artículos.
"Seguimiento de ruta de GPU" parte 1, parte 2 y "Representación imparcial".
En resumen: se trata de un renderizado que no introduce errores sistemáticos en el cálculo y reproduce efectos físicamente precisos.

• iluminación global
• sombras suaves, reflejos realistas
• profundidad de campo y desenfoque de movimiento
• dispersión del subsuelo y más

Debido a la autenticidad física y la calidad de la imagen, este enfoque obviamente requiere muchos recursos. El problema se puede resolver transfiriendo cálculos a la GPU, ya que este enfoque aumenta la velocidad de cálculo hasta 50 veces para cada dispositivo GPU.

1200x600 (se puede hacer clic), AMD Radeón HD 6870, tiempo de renderizado: 9 minutos

Por qué Direct3D

Existen muchas plataformas GPGPU (OpenCL, CUDA, FireStream, DirectCompute, C++ AMP, Shaders, etc.), pero existe controversia sobre elección óptima Todavía continúan y no hay una respuesta clara sobre cuál es mejor utilizar. Veamos los principales argumentos a favor de Direct3D que nos persuadieron a elegir esta API en particular:

• Funciona en toda la gama de tarjetas de video, emulado en todos los modelos de procesador: el mismo sombreador funciona en todas partes
• Son las especificaciones de Direct3D las que marcan la dirección para el desarrollo del hardware de consumo.
• Siempre el primero en recibir los controladores más recientes y estables
• Otras tecnologías de proveedores cruzados no son estables o tienen poco soporte

De OpenCL y Direct3D, elegimos el mal que al menos tiene controladores estables, perfeccionados durante décadas en la industria del juego y que tiene mejor rendimiento en una serie de puntos de referencia. Además, debido a la tarea, se descartó CUDA, a pesar de todas las herramientas, una gran cantidad de ejemplos y una sólida comunidad de desarrolladores. C++ AMP aún no se había anunciado en ese momento, pero desde... Su implementación se basa en DirectX, por lo que transferirle el renderizado no planteará ningún problema especial.
También se consideró la combinación OpenGL/GLSL, pero fue rápidamente descartada debido a las limitaciones que DirectX resuelve usando DirectCompute (problemas de seguimiento de ruta bidireccional, etc.).

Además, observamos la situación con los controladores GPGPU para hardware de consumo, que se lanzan tarde y tardan mucho en alcanzar la estabilidad. Entonces, cuando se lanzó la línea NVIDIA Kepler 600, los jugadores recibieron inmediatamente controladores Direct3D de alta calidad y máquinas de juego más potentes, pero mayoría Las aplicaciones GPGPU han perdido su compatibilidad o se han vuelto menos eficientes. Por ejemplo, Octane Render y Arion Render, construidos sobre CUDA, comenzaron a soportar la línea Kepler el otro día. Además, el hardware GPGPU profesional no siempre es mucho mejor en una serie de tareas, como se describe en el artículo “NVidia para aplicaciones 3D profesionales”. Esto da una razón para recolectar puesto de trabajo específicamente en hardware de juegos de consumo.

¿Por qué no Direct3D?

En todos los anuncios de DirectX 10‒11 escriben que los nuevos modelos de sombreadores son ideales para el trazado de rayos y muchas otras tareas GPGPU. Pero nadie realmente aprovechó esta oportunidad. ¿Por qué?

• Sin herramientas ni soporte
• La investigación se desplazó hacia NVIDIA CUDA debido al fuerte marketing
• Vinculación a una plataforma

Retrocedamos un año. Última actualización DX SDK se lanzó en julio de 2010. No hay integración con VisualStudio, no existe una comunidad de desarrolladores GPGPU ni ejemplos de alta calidad de normalidad. tareas informáticas prácticamente ninguno. ¡No hay resaltado de sintaxis de sombreado! Tampoco existen herramientas de depuración sensatas. PIX no puede manejar múltiples bucles anidados o un sombreador de más de 400 líneas de código. D3DCompiler podría fallar de vez en cuando y tardar decenas de minutos en compilar sombreadores complejos. Infierno.

Por otro lado, hay una mala implementación de la tecnología. Mayoría artículos científicos y las publicaciones se escribieron utilizando CUDA y adaptadas al hardware NVIDIA. El equipo de NVIDIA OptiX tampoco está particularmente interesado en realizar investigaciones para otros proveedores. empresa alemana mentalimages, que ha acumulado décadas de experiencia y patentes en este ámbito, ahora también es propiedad de NVIDIA. Todo esto crea un sesgo nocivo hacia un solo proveedor, pero el mercado es un mercado. Para nosotros, todo esto significó que teníamos que explorar de nuevo todas las nuevas técnicas de trazado y renderizado de GPGPU, pero sólo en DirectX y en hardware ATI e Intel, lo que a menudo conducía a resultados completamente diferentes, por ejemplo en la arquitectura VLIW5.

Implementación

Solucionamos problemas
Antes de describir la implementación, daré algunos consejos útiles que nos ayudaron en el desarrollo:

• Si es posible, cambie a VisualStudio2012. Integración tan esperada con DirectX, depuración de sombreadores incorporada y, he aquí, el resaltado de sintaxis HLSL le ahorrará mucho tiempo.
• Si VS2012 no es una variante, puede utilizar las herramientas Tipo de NVIDIA Parallel Nsight, pero nuevamente hay una vinculación a un tipo de GPU.
• Usa el SDK de Windows 8.0, ese es tu hermano. Incluso si te desarrollas Vista de Windows/ 7 y versiones anteriores de VisualStudio, tendrá a su disposición las últimas bibliotecas D3D, incluido el último D3DCompiler, que reduce el tiempo de compilación del sombreador de 2 a 4 veces y funciona de manera estable. Hay un manual detallado para configurar DirectX desde el SDK de Windows 8.0.
• Si todavía estás usando D3DX, considera dejarlo, no es hermano. El SDK de Windows 8.0 dejó de admitirlo por razones muy obvias.

Rasterización vs rastreo
A pesar de que se utiliza DirectX, no se habla de rasterización. No se utiliza el Pipeline estándar de sombreadores de vértices, casco, dominio, geometría y píxeles. se trata de sobre el trazado de trayectorias de luz utilizando sombreadores de píxeles y Compute. La idea de combinar rasterización + rastreo, por supuesto, surgió, pero resultó muy difícil de implementar. La intersección del primer rayo se puede reemplazar por rasterización, pero después es muy difícil generar rayos secundarios. A menudo resultaba que los rayos estaban debajo de la superficie y el resultado era incorrecto. A la misma conclusión llegaron los chicos de Sony Pictures Imageworks, que desarrollaron Arnold Renderer.

Representación
Hay dos enfoques principales para organizar el renderizado:

1. Todos los cálculos se realizan en el meganúcleo. Programas de GPU, que es responsable tanto del trazado como del sombreado. Esto es lo mas manera rápida representación. Pero si la escena no cabe en la memoria de la GPU, entonces se intercambiará la escena o la aplicación fallará.
2. Representación fuera del núcleo: solo la geometría de la escena o parte de ella se transfiere a la GPU, junto con un búfer de rayos para el trazado, y se realiza el trazado de rayos de múltiples pasadas. El sombreado se realiza en la CPU o con otra pasada en la GPU. Estos enfoques no son conocidos por su sorprendente rendimiento, pero permiten renderizar escenas del tamaño de una producción.

Nos decidimos por la primera opción usando sombreadores para GPGPU, pero antes de renderizar algo, debemos preparar la geometría y los datos de la escena, colocándolos correctamente en la memoria de la GPU.
Los datos de la escena incluyen:

• geometría (vértices, triángulos, normales, coordenadas de textura)
• estructura de aceleración (árbol Kd o nodos BVH)
• Materiales de superficie (tipo, colores, indicadores de textura, expositores reflectantes y más)
• texturas de materiales, mapas normales, etc.
• fuentes de iluminación (singulares y extendidas)
• posición y parámetros de la cámara, como DOF, FOV, etc.

No se utilizan buffers de índice o vértice durante el renderizado. En Direct3D11, los datos están unificados, todo se almacena en el mismo formato, pero puedes decirle al dispositivo cómo verlo: como Buffer, Texture1D/2D/3D/Array/CUBE, RenderTarget, etc. Los datos a los que se accede de forma más o menos lineal se almacenan mejor en forma de buffers. Los datos con acceso caótico, por ejemplo, estructuras de escena aceleradas, se almacenan mejor en una textura, porque con accesos frecuentes, parte de los datos se almacenarán en caché.
Es razonable almacenar datos pequeños y que cambian rápidamente en búferes constantes, estos son parámetros de la cámara, fuentes de iluminación y materiales, si no hay muchos y caben en un búfer de tamaño 4096 x float4. En el renderizado interactivo, cambiar la posición de la cámara, ajustar los materiales y la luz es la operación más común. Los cambios de geometría ocurren con menos frecuencia, pero todavía no hay suficiente memoria constante para acomodarlos.

Porque Hay relativamente poca memoria en la GPU, es necesario utilizar enfoques inteligentes para su organización e intentar empaquetar todo lo que se pueda empaquetar y utilizar compresión de datos. Colocamos las texturas de los materiales en un atlas de texturas multicapa, porque... La cantidad de ranuras de texturas de GPU es limitada. Además, la GPU tiene formatos de compresión de texturas integrados, DXT, que se utilizan para atlas de texturas y pueden reducir el tamaño de las texturas hasta 8 veces.

Empaquetando texturas en el atlas:

Como resultado, la ubicación de los datos en la memoria se ve así:

Se supone que los datos luminosos y materiales podrán encajar en registros constantes. Pero si la escena es lo suficientemente compleja, los materiales y las luces se colocarán en la memoria global, donde debería haber suficiente espacio para ellos.

Pasemos al renderizado: en el sombreador de vértices dibujamos un quad, el tamaño de la pantalla, y usamos la técnica de mapeo de texel a píxel para que cuando se rasterice, cada píxel del sombreador de píxeles tenga las coordenadas de textura correctas y, por lo tanto, , valores correctos x e y en la pantalla.


A continuación, para cada píxel del sombreador, se calcula un algoritmo de trazado de rayos. Este método produce GP Computación GPU en sombreadores de píxeles. Este enfoque puede no parecer el más óptimo y sería más razonable utilizar DirectCompute, para el cual no es necesario crear sombreadores de vértices ni pantallas cuádruples. Pero numerosas pruebas han demostrado que DirectCompute es entre un 10 y un 15 % más lento. En un problema de seguimiento de ruta, cualquier beneficio de usar SharedMemory o usar ráfagas de rayos se anula rápidamente debido a la naturaleza aleatoria del algoritmo.

Se utilizan dos técnicas para el renderizado: la vista interactiva funciona sobre un Path Tracing unidireccional modificado, y para el renderizado final se puede utilizar el Path Tracing bidireccional, porque su velocidad de fotogramas no es muy interactiva en escenas complejas. El muestreo mediante el método Metropolis Light Transport aún no se utiliza, porque su eficacia aún no se ha justificado, como dice uno de los desarrolladores de V-Ray en el foro cerrado de ChaosGroup:

vlado publicó:

“...Llegué a la conclusión de que la MLT está muy sobrevalorada. Puede resultar muy útil en algunas situaciones especiales, pero para la mayoría En escenarios cotidianos, su rendimiento es (mucho) peor que un trazador de ruta bien implementado. Esto se debe a que MLT no puede aprovechar ningún tipo de ordenamiento de muestras (por ejemplo, muestreo cuasi-Monte Carlo, o la secuencia de Schlick que usamos, o muestreo de N torres, etc.). Un renderizador MLT debe recurrir a números aleatorios puros, lo que aumenta en gran medida el ruido en muchas escenas simples (como una escena con un tragaluz abierto)”.

Multinúcleo. Multidispositivo. Nube.

Observemos lo bueno de la renderización imparcial: se basa en el método de Monte Carlo, lo que significa que en caso general Cada iteración de renderizado es independiente de la anterior. Esto es exactamente lo que hace este algoritmo Atractivo para la informática en GPU, sistemas multinúcleo y clústeres.

Para admitir hardware de las clases DX10 y DX11 y no tener que reescribir todo de nuevo para cada versión, debe usar DirectX11, que se ejecuta en hardware DX10 con restricciones menores. Teniendo soporte para una amplia clase de hardware y la predisposición del algoritmo a la distribución, creamos el renderizado multidispositivo, cuyo principio es muy simple: es necesario colocar los mismos datos y sombreadores en cada GPU y simplemente recopilar el resultado de cada GPU. cuando esté listo, reiniciando el renderizado cuando cambie de etapa. El algoritmo le permite distribuir el renderizado en una gran cantidad de dispositivos. Este concepto es excelente para la computación en la nube. Pero no hay muchos proveedores de GPU en la nube y el tiempo de uso de la computadora tampoco es muy barato.

Con la llegada de DirectX11, una tecnología maravillosa vino al rescate: WARP (Plataforma de rasterización avanzada de Windows). El dispositivo WARP traduce el código de su GPU en código multiproceso optimizado para SSE, lo que le permite realizar cálculos de GPU en todos Núcleos de CPU. Además, absolutamente cualquier CPU: x86, x64 e incluso ARM. Desde el punto de vista de la programación, un dispositivo de este tipo no se diferencia de un dispositivo GPU. Es sobre la base de WARP que se implementa C++ AMP computación heterogénea. El dispositivo WARP también es tu hermano, usa el dispositivo WARP.

Gracias a esta tecnología, pudimos lanzar el renderizado de GPU en la nube de la CPU. Un poco acceso libre Obtuvimos acceso a Windows Azure a través del programa BizSpark. Se utilizó Azure Storage para almacenar los datos, los datos con geometría de escena y texturas se almacenaron en "blobs", los datos sobre trabajos de renderizado, descarga y descarga de escenas estaban en colas (Colas). Para asegurar operación estable Se utilizaron tres procesos: el distribuidor de tareas (Work Scheduler), el observador de procesos ( Monitor de proceso) y un proceso que descarga imágenes renderizadas (Image Downloader). Work Scheduler es responsable de cargar datos en blobs y configurar tareas. Process Monitor es responsable de mantener a todos los trabajadores (Trabajador - nodo informático de Azure) en buen estado de funcionamiento. Si uno de los trabajadores deja de responder, entonces se inicializa una nueva instancia, asegurando así máximo rendimiento sistemas. Image Downloader recopila piezas renderizadas de la imagen de todos los trabajadores y transfiere el acabado o imagen intermedia al cliente. Una vez que se completa la tarea de renderizado, Process Monitor elimina las imágenes de los trabajadores para que no haya recursos inactivos por los que pagar.

Este esquema funciona bien y nos parece que este es el futuro del renderizado: Pixar ya renderiza en la nube. Normalmente, los precios de la nube se aplican sólo al tráfico descargado, que consiste en imágenes renderizadas de no más de unos pocos megabytes de tamaño. El único cuello de botella de este enfoque es el canal de usuario. Si necesita renderizar animaciones con tamaños de activos de varias decenas o cientos de GB, entonces tiene problemas.

Resultado

El resultado de todo este trabajo fue el complemento RenderBro para Autodesk 3DS Max, que, según lo previsto, debería renderizarse incluso en la computadora de la abuela y puede utilizar cualquier recurso informático.

Actualmente se encuentra en la etapa de prueba alfa cerrada. Si es un entusiasta de las GPU, un artista 3D, está planeando construir un clúster ATI/NVIDIA, tiene un montón de GPU y CPU diferentes o cualquier otra configuración interesante, hágamelo saber, será interesante trabajar juntos. Realmente me gustaría probar el renderizado en algo como esto:

Además, hay una versión C++ AMP de renderizado más adelante, más seria. pruebas en la nube y desarrollar complementos para otros editores. ¡Únete a nosotros!

Podemos seguir y seguir sobre el renderizado de GPU. En el pasado reciente, el potencial de las tarjetas de video se reveló mucho peor y se usaron solo en trabajos preparatorios, y no se usaron para renderizado completo y ni siquiera imaginaron tal posibilidad. Hoy en día, las tecnologías GPU se utilizan ampliamente para el renderizado de producción y los métodos de implementación no se limitan a las estaciones de trabajo Octane. Incluso el renderizado en la nube ahora es posible en las GPU Procesadores NVIDIA y Octano. Y por supuesto, siempre puedes subcontratar completamente el trabajo a terceras empresas a través de Internet, delegando por completo la tarea de renderizado.

Guerra de marcas y tecnologías

Sin embargo, la realidad de la GPU no es ideal y contiene dos varias tecnologías. Este es CUDA completamente diseñado para Nvidia y OpenCL. A pesar de que OpenCL es un proyecto de código abierto, el número de fans y profesionales aquí es menor que el de Nvidia. El mercado del renderizado presenta una situación similar, indicando una simple división del mercado sin una división específica en esferas de influencia.
El desarrollador de la tecnología Maxwell está interesado en el mercado de GPU y lleva varios meses observando el enfrentamiento CUDA/OpenCL. Next Limit, si se restablece la armonía, planea desarrollar activamente nuevas plataformas GPU. El representante de Next Limit, Juan Canada, enfatiza que, a pesar del deseo de la campaña de desarrollarse y mantenerse al día, esto solo es posible con riesgos mínimos de disminución de la calidad y funcionalidad de Maxwell. Por lo tanto, es importante que tengan confianza en la estabilidad del mercado de GPU.

resumámoslo

La GPU finalmente ha entrado en el mundo del renderizado, aunque no ha tomado su forma definitiva y todavía está sufriendo cambios y actualizaciones. Y esto está dando sus frutos: las obras obtenidas mediante este tipo de renderizado se acercan cada vez más a la calidad de imagenes realistas. Si antes el trabajo de GPU parecía dibujos o escenas de juegos de computadora, ahora a menudo es indistinguible de una representación cinematográfica profesional. Pero trabajar con la CPU plantea muchas dificultades, por ejemplo, escribir código que debe seleccionarse según muchos parámetros para adaptarse a su computadora. Otro defecto importante es que la GPU no contiene todos los algoritmos de las arquitecturas de procesadores de vídeo.

Buenos días, queridos lectores.

Permítanme hacer una reserva de inmediato: este artículo no es una revisión detallada, solo pretende esquema general Presente a los principiantes el renderizado RT utilizando una tarjeta de vídeo.

representaciones sesgadas e imparciales

Según el principio de funcionamiento, todos los renders se pueden dividir en 2 grandes grupos.

Sesgado- estos son renderizadores adaptativos que calculan todo efectos fisicos uno por uno, y luego conéctelos de acuerdo con la configuración, accesible al usuario. La adaptabilidad se expresa en la presencia de una gran cantidad de configuraciones que afectan la calidad de la imagen final.

El renderizador sesgado primero creará un mapa de luz de todo el espacio para sí mismo, luego lo "superpondrá" sobre la geometría para comprender qué áreas calcular con precisión y cuáles no. Digamos que "ve" que el área en la esquina de la habitación prácticamente no está iluminada. Comprueba la configuración y reduce la calidad de procesamiento de esta área a especificado por el usuario mínimo: ¿por qué realizar cálculos complejos si los objetos se encuentran en sombras intensas y deslumbramientos, reflejos, etc., en cualquier caso no serán claramente visibles en ellos?

Imparcial- Estos son los llamados "motores físicamente correctos". Toman la escena completa y comienzan a calcularla con esencialmente “escenarios infinitos”. En la práctica, esto sucede así: al principio toda la imagen tiene una calidad terrible y un ruido terrible. A medida que avanza el renderizado, el ruido comienza a desaparecer y la calidad de toda la imagen comienza a mejorar.

¿De qué tipo es el popular motor V-Ray?

V-Ray puede funcionar en ambos modos. El cambio se realiza así: F10-Common-Assign Render (en la parte inferior)

• VRay Adv - Sesgado
• VRay RT - Imparcial

¿Cómo se aplica todo esto a las tarjetas de video?

La renderización en una tarjeta de vídeo (renderización GPU) sólo es posible en el “modo” imparcial. De aquí tenemos el primer punto controvertido.

Por un lado en tarjetas de video modernas muchos más núcleos que en procesadores modernos. A los especialistas en marketing les gusta mencionar esto a menudo =)

Por ejemplo, el 660 Ti, según la especificación, tiene 1344 núcleos. Y el procesador es 4 físicos y 8 virtuales.

Por otro lado, estos núcleos son como soldados de un batallón de construcción, dispuestos a trabajar con palas “de aquí a mañana”. No saben cómo pensar y optimizar su trabajo, por lo que el volumen de este trabajo aumenta desproporcionadamente. Los especialistas en marketing guardan silencio al respecto.

¿Qué render es mejor?

Imparcial, es decir El renderizado por GPU le permite obtener una imagen físicamente más correcta, pero lleva mucho más tiempo incluso en tarjetas de video potentes.

Además, al intentar estimar la diferencia en tiempo real, surge una dificultad: En esencia, la representación imparcial es infinita,Puede contar la imagen para siempre, mejorándola constantemente.La única pregunta es cuándo una persona dejará de notar la diferencia y, como comprenderá, esta línea no tiene límites claros.

El renderizado en el procesador (CPU) le permite obtener una imagen de alta calidad mucho más rápido con un nivel de fotorrealismo completamente aceptable. Sin embargo, vale la pena considerar que la calidad de la imagen cuando la renderiza un procesador depende en gran medida de la capacidad de configurar el motor de renderizado.

¿Qué debería elegir un principiante?

Para un principiante, no es necesario prestar atención a la GPU.

• Este es el render más largo. No es en absoluto adecuado para el proceso de aprendizaje, que implica crear una gran cantidad de imágenes preliminares;
• El uso práctico de GPU no está justificado en todas las tareas e implica el uso únicamente de tarjetas de video costosas. Si es un principiante, estas tareas no le aparecerán pronto.