Página 3 de 4 PrimerPrimer 1234 ÚltimoÚltimo
Resultados 41 al 60 de 64
Like Tree13Likes

Tema: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

  1. #41
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    What Exactly Is a Draw Call (and What Can It Do)?

    It's Basically a Function Call for GPUs

    Mantle, Vulkan, and DirectX 12 all claim to reduce overhead and provide a staggering increase in “draw calls”. As mentioned in the previous editorial, loading graphics card with tasks will take a drastic change in these new APIs. With DirectX 10 and earlier, applications would assign attributes to (what it is told is) the global state of the graphics card. After everything is configured and bound, one of a few “draw” functions is called, which queues the task in the graphics driver as a “draw call”.
    While this suggests that just a single graphics device is to be defined, which we also mentioned in the previous article, it also implies that one thread needs to be the authority. This limitation was known about for a while, and it contributed to the meme that consoles can squeeze all the performance they have, but PCs are “too high level” for that. Microsoft tried to combat this with “Deferred Contexts” in DirectX 11. This feature allows virtual, shadow states to be loaded from secondary threads, which can be appended to the global state, whole. It was a compromise between each thread being able to create its own commands, and the legacy decision to have a single, global state for the GPU.
    Some developers experienced gains, while others lost a bit. It didn't live up to expectations.
    The paradigm used to load graphics cards is the problem. It doesn't make sense anymore. A developer might not want to draw a primitive with every poke of the GPU. At times, they might want to shove a workload of simple linear algebra through it, while other requests could simply be pushing memory around to set up a later task (or to read the result of a previous one). More importantly, any thread could want to do this to any graphics device.
    The new graphics APIs allow developers to submit their tasks quicker and smarter, and it allows the drivers to schedule compatible tasks better, even simultaneously. In fact, the driver's job has been massively simplified altogether. When we tested 3DMark back in March, two interesting things were revealed:

    • Both AMD and NVIDIA are only a two-digit percentage of draw call performance apart
    • Both AMD and NVIDIA saw an order of magnitude increase in draw calls

    Read on to see what this means for games and game development.
    The number of simple draw calls that a graphics card can process in a second does not have a strong effect on overall performance. If the number of draw calls in the DirectX 12 results are modeled as a latency, which is not the best way to look at it but it helps illustrate a point, then a 10% performance difference is about five nanoseconds (per task). This amount of time is probably small compared to how long the actual workload takes to process. In multi-threaded DirectX 11, NVIDIA held a lead over AMD by about 162% more calls. This almost three-fold increase in draws, which is a precious resource in DirectX 11, was evaporated in DirectX 12. In fact, it was AMD who held about a 23% lead in that API, although DX12 calls are more plentiful than they were in DX11. Are draw calls no longer a bottleneck in DirectX 12, though? We'll see.

    If they're able to see the whole level, that's ~9000 draw calls.Many can be instanced together, but that's added effort and increases GPU load.
    This brings us to the second point: both vendors saw an order of magnitude increase in draw calls. When this happens, developers can justify solving their problems with smaller, more naive tasks. This might be able to either save real development time that would be spent on optimization if DX11 can be ignored, or it may allow a whole new bracket of cosmetic effects for compatible systems. This is up to individual developers, and it depends on how much real-world relief it brings.
    A couple of months ago, I talked to a “AAA” game developer about this. He was on the business side, so I focused the conversation on how the new APIs would affect corporate structure.
    I asked whether this draw call increase would trickle into the art department and asset creation. Specifically, I inquired whether the reduced overhead would allow games to be made on smaller art budgets, and/or this permit larger games on the same budget. Hypothetically, due to the decrease in person-hours required to optimize (or sometimes outright fake) complex scenes, the artists would spend less time on the handful of difficult assets that require, for instance, multiple materials or duplications of skeletal meshes, each of which are often separate draw calls. For instance, rather than spawning a flock of individual birds, an artist could create a complex skeleton animation for the entire flock to get it in one draw call. This takes more time to create, and it will consume extra GPU resources used to store and animate that hack too, which means you will probably need to spendeven more time elsewhere to pay that debt.

    A nine-bone skeleton even looks like a terrible way to animate three book-shaped birds.But... it's one draw call.
    This apparently wasn't something that the representative thought much about but, as he pondered about it for a few moments, he said that he could see it leading to more content within the same art budget. This hesitation surprised me a bit, but that could have just been the newness of the question itself. I would have expected that it would have already influenced human resource decisions if my hypothesis was true, which wouldn't require time to reflect upon.
    But other studios might be thinking of it.
    Ubisoft's CEO mentioned in an investor call that Assassin's Creed: Unity was the product of redoing their entire engine. Graphics vendors state that amazing PC developers should be able to push about 10,000 to 20,000 draw calls per frame with comfortable performance. This Assassin's Creed, on the other hand, was rumored to be pushing upwards of 50,000 at some points, and some blame its performance issues on that. It makes me wonder how much changed, company wide, for an instantaneous jump to that many draw calls to have happened.

    Ubisoft took the plunge.
    We might not see the true benefit of these new APIs until they grow in popularity. They have the potential to simplify driver and game development, which the PC genuinely needs. Modern GPUs operate a lot closer to their paradigm in GPU Compute APIs, with some graphics functionality added, than they did in the 1990s versions of DirectX and OpenGL. Trying to shoe-horn them into the way we used to interface with them limits them, and it limits the way we develop content for them.
    This (mostly) isn't free performance, but it frees performance the more it influences development.

    What Exactly Is a Draw Call (and What Can It Do)? | PC Perspective

  2. #42
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia


  3. #43
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    NVIDIA Releases Mirror’s Edge Catalyst Video Featuring Design Director talk about Frostbite, Animations and Reflections



    Read more: NVIDIA Releases Mirror's Edge Catalyst Video Featuring Design Director talk about Frostbite, Animations and Reflections

  4. #44
    Pajarito Nuevo
    Fecha de ingreso
    16 Sep, 15
    Mensajes
    22

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Buen post! buena informacion!

  5. #45
    Master Avatar de fogever
    Fecha de ingreso
    16 Nov, 15
    Mensajes
    108

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Buen post, sería bueno actualizarlo con info más actual. Saludos

  6. #46
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Adaptative vsync en Nvidia





    Fresync AMD

    Última edición por Activity; 02/10/2016 a las 02:50

  7. #47
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    ANÁLISIS A FONDO: ARQUITECTURA GPU NVIDIA PASCAL – DISEÑADA PARA LA VELOCIDAD


    El avance continuo de las unidades de procesamiento gráfico o GPUs de alto desempeño y completamente programables de NVIDIA ha llevado a mejoras tremendas en la computación de gráficos 3D y aceleradas por GPU. Esta constante evolución del GPU hace posible las hermosas gráficas que los consumidores disfrutan el día de hoy en juegos y películas, y ademas en avances en la Inteligencia Artificial, el Deep Learning, sistemas de conducción autónomos y un sin numero de aplicaciones de computo-intensivo.Basada en la revolucionaria arquitectura NVIDIA Pascal, que fue introducida en el GPU GP100 para servidores y datacenters, El próximo GPU de NVIDIA basado en Pascal -el GP104- es el que será responsable de empujar la nueva generación de gráficos DirectX 12 y Vulkan; potenciar los equipos de Realidad Virtual o (VR por sus siglas en ingles), juegos y aplicaciones ademas de dar soporte 4K, 5K, y pantallas HDR con una increíble fidelidad.La primera tarjeta gráfica que traerá consigo el nuevo GPU GP104 es la GeForce GTX 1080.Como uno de los lideres en la computación visual, NVIDIA ha sido el pionero de muchas innovaciones en el hardware de GPU y tecnologías de software. Pascal entrega un gran aumento en velocidad y mejoras en la jugabilidad en PC, y las librerías de software GameWorks de NVIDIA permite que desarrolladores puedan implementar experiencias mas interactivas y cinemáticas. El desempeño de la nueva GeForce GTX 1080 combinada con las librerías GameWorks permiten efectos visuales, simulaciones físicas y experiencias VR para la jugabilidad en PC. Los beneficios combinados de la nueva arquitectura Pascal y sus implementaciones, el proceso de manufactura de 16nm FinFET y las ultimas tecnologías de memorias GDDR5X le dan a la GeForce GTX 1080 un 70% mas de rendimiento por sobre la generación anterior de GPUs, como la GeForce GTX 980.Con 2560 núcleos CUDA corriendo a velocidades sobre los 1600MHz en la GeForce GTX 1080, el GP104 es el GPU más rápido del mundo. Pascal también es una de las arquitecturas mas eficientes del mundo: la GeForce GTX 1080 es 1.5x veces mas eficiente que la GTX 980 y 3x veces mas eficiente que la GTX 780.La Geforce GTX 1080 no solo permite que los gamers puedan experimentar sus juegos favoritos con gran detalle, simulaciones mejores, y mas cuadros por segundo que antes, si no que también entrega una cantidad mucho mas consistente en la taza de cuadros por segundo y una experiencia de juego mas suave. NVIDIA ha desarrollado una gran cantidad de nuevas tecnologías que están diseñadas para reducir los saltos y otros elementos distractivos que puedan comprometer la experiencia de juego. También se han desarrollado nuevas técnicas de renderizado que están diseñadas para reducir la latencia y mejorar el desempeño en juegos VR. En este articulo encontraras todo lo relacionado con las nuevas tecnologías que NVIDIA ha integrado en la arquitectura Pascal para hacer todo esto posible.Innovaciones de Pascal

    Las demandas en el GPU para los PC entusiastas nunca han sido tan grandes. Resoluciones de pantalla que continúan creciendo, con pantallas 4K y 5K que requieren GPUs extremadamente poderosas (o múltiples GPU) para mantener los FPS estables y con una calidad de imagen alta. Los equipos de VR ahora piden como mínimo que entreguen al menos 90FPS, por cada ojo, y con una latencia muy baja para asegurar una experiencia inmersiva para que se mueva en conjunto con el usuario. La GeForce GTX 1080 fue diseñada con estas tecnologías en mente. Las características principales son:Arquitectura Pascal

    La arquitectura Pascal que se encuentra en la GTX 1080 es la mas eficiente jamas construida. Consiste de 7.2 mil millones de transistores e incluye 2560 núcleos CUDA single-precisión. Con un foco intenso en la manufactura en el chip y en el diseño de la placa, el equipo de ingeniería de NVIDIA logro resultados sin precedentes en frecuencia y eficiencia energética.16nm FinFET

    el GPU GP104 es fabricado en el proceso de 16nm FinFET el cual permite que el chip sea fabricado con mas transistores para que así se puedan activar nuevas características, mas desempeño y una mejora en la eficiencia.Memoria GDDR5X

    GDDR5X provee una mejora en el ancho de banda de memoria por sobre GDDR5, la cual se utilizaba en la generación anterior de GPUs tope de linea de NVIDIA. Corriendo a una taza de transferencia de datos de 10Gbps, la interfaz de memoria de la GTX 1080 entrega un 43% mas de ancho de banda que su predecesora, la GTX 980. Combinado con las mejoras de compresión de memoria, el ancho de banda total efectivo, cuando se le compara con al GTX980 es de 1.7 veces.Simultaneous Multi-Projection (SMP)

    El campo de la tecnologia de pantallas esta efectuando cambios significativos desde los dias de una sola pantalla plana. Reconociendo esta moda, los ingenieros de NVIDIA desarrollaron una tecnologia denominada Simultaneous MultiProjection que por primera vez permite que el GPU simultáneamente mapee un primitivo en hasta dieciséis proyecciones diferentes desde el mismo punto de vista. Cada proyección puede ser mono o estéreo. Esta capacidad permite a la GTX 1080 pueda aproximar precisamente la proyección curva requerida para pantallas VR, los ángulos de proyección múltiple requeridos para configuraciones de pantallas surround y otros usos en el futuroArquitectura de GPU – GP104 en profundidad

    Los GPUs Pascal están compuestos de diferentes configuraciones de GPCs o Graphics Processing Clusters, SM o Streaming Multiprocessors, y controladores de memoria. Cada SM se encuentra pareado con un Motor PolyMorph que maneja lectura de vértices, teselacion, transformación de viewport, configuración de los atributos de vértices, y corrección perspectiva. El motor PolyMorph del GP104 también incluye una nueva unidad de Multiproyeccion Simultanea que describiremos más adelante. La combinación de un SM mas un Motor PoliMorph es conocida como TPC.El GPU GP104 abordo de la GeForce GTX 1080 consiste de cuatro GPCs, veinte Streaming Multiprocessors Pascal y ocho controladores de memoria. En la GeForce GTX 1080, cada GPC viene equipado con un motor de rasterizado dedicado y cinco SM. Cada SM contiene 128 núcleos CUDA, 256 KB de capacidad de archivos de registro, 96 KB de unidad de memoria compartida 48 KB de almacenamiento total para el cache L1 y ocho unidades de textura.El SM es un poderoso multiprocesador paralelo que agenda warps (grupos de 32 hilos) a núcleos CUDA y otras unidades de ejecución dentro del SM. El SM es una de las unidades de hardware mas importantes dentro del GPU, casi todas las operaciones fluyen a través del SM en algún momento en la pipeline de renderizado. Con 20 SMs la GeForce GTX 1080 viene equipada con un total de 2560 núcleos CUDA y 160 unidades de Textura.También, la GeForce GTX 1080 viene equipada con ocho controladores de memoria de 32-bit (un total de 256-bit). Enlazados a cada controlador de memoria de 32-bit hay ocho unidades ROP y 256KB de cache L2. El chip Gp104 utilizado en la GTX 1080 viene con un total de 64 ROPs y 2048 KB de cache L2.La siguiente tabla provee un alto nivel de comparación entre la Geforce GTX 1080 versus la generación anterior de GeForce.Arquitectura Pascal: Diseñada para la velocidad.

    La artesanía detrás de todos los aspectos del diseño del GPU fue el foco principal en el esfuerzo del desarrollo de Pascal. Como mencionábamos anteriormente, Pascal es el GPU mas eficiente enigmáticamente a la fecha, y no solo por el proceso 16FF, sino que también por la continua mejora del consumo energético en la implementación de GPU. La frecuencia de reloj fue otra área de gran inversión para el equipo de ingeniería de NVIDIA. La frecuencia es establecida no por el camino tiempo promedio de circuito en el diseño, si no que por el camino mas lento dentro de millones de caminos de tiempo. Un diseño cuidadoso y la optimización de caminos críticos es crucial para asegurar que la capacidad del diseño en general no sea restringida. Como resultado del esfuerzo en esta área, la GeForce GTX 1080 entrega un aumento de un 40% en la Frecuencia Boost comparada con una GTX 980, bastante mas arriba en de lo que el proceso de 16nm FF hubiera alcanzado solo.Memoria GDDR5X

    Desde la introducción de las memorias GDDR5 en 2009, los diseñadores de memoria de NVIDIA han estudiado las posibilidades para la próxima generación de tecnologías de memora. GDDR5X es la culminación de ese esfuerzo: GDDR5X es el estándar de interfaz de memoria mas rápido y avanzado de la historia alcanzando velocidades de transferencia de hasta 10 Gbps o casi 100 picosegundos (ps) entre bits de datos. Para poner esa velocidad en contexto de señal, considera que la luz viaja cerca de una pulgada en 100 ps de tiempo. Un circuito IO GDDR5X tiene menos de la mitad de ese tiempo disponible para muestrear un bit cuando llegue, o la información se perderá mientras el bus pasa a un nuevo set de valores.Para lograr esta operación de alta velocidad, una nueva arquitectura de circuito IO era necesaria y requirió un proyecto de desarrollo de años incorporando los últimos avances en la materia. Cada aspecto del nuevo diseño fue cuidadosamente diseñado para cumplir los estándares exactos de operación de alta frecuencia. Con esto, también se lograron mejoras de desempeño energético a través de la combinación de estas ventajas de circuitería, el bajo voltaje de 1.35V como estándar de GDDR5X y un nuevo proceso tecnológico, resultaron en el mismo consumo eléctrico a un 43% mas de frecuencia.Ademas, el “canal” entre el die del GPU y el die de la memoria tuvieron que ser diseñados con una gran atención al detalle. la velocidad de operación de la interfaces es determinada solamente por la velocidad de la señal mas débil del bus. Cada señal entre el GPU y el die de memoria fue cuidadosamente estudiada junto con el camino completo fuera del GPU, a través del empaque, hacia la placa y sobre el die de la memoria, con atención a la perdida de canal, crosstalk y discontinuidades que pudieran degradar la señal.En total, las mejoras de circuito y canal descritas anteriormente no solamente permiten que GDDR5X funcione a 10Gbps, si no que también proveen beneficios que serán útiles para otros productos que utilicen memorias GDDR5X.Las siguientes imágenes muestran algunos elementos de diseño, incluyendo el diseño IO del circuito, un modelo extraído de un camino de una señal, en amarillo, desde el GPU (arriba a la izquierda) hacia los pads de DRAM (abajo a la derecha) en el nuevo diseño de la placa de la GeForce GTX 1080.Compresión de memoria mejorada

    Como las GPUs anteriores, el subsistema de memorias de la GeForce GTX 1080 utiliza técnicas de compresión de memoria sin perdida para reducir la demanda de ancho de banda de DRAM. La reducción del ancho de banda entregada por la compresión de memoria provee un numero de beneficios:
    • Reduce la cantidad de datos escritos en memoria
    • Reduce la cantidad de datos transferidos desde memoria al cache L2; efectivamente entregando un incremento en capacidad para el cache L2, ya que las baldosas comprimidas (un bloque de framebuffer de pixeles o muestreos) tiene una huella de memoria más pequeña que una baldoza no comprimida.
    • Reduce la cantidad de datos transferidos entre clientes como las Unidades de Textura y el frame buffer.

    La linea de compresión del GPU tiene un numero diferente de algoritmos que inteligentemente determinan la forma mas eficiente de comprimir información. Uno de los algoritmos mas importante es el la compresión de color delta. Con la compresión delta de color, el GPU calcula las diferencias entre pixeles en un bloque y almacena el bloque como un ser de pixeles de referencia ademas de los valores delta de referencia. Si los valores deltas son menores, entonces solo un par de bits por pixel son necesarios. Si el empaque en conjunto de valores de referencia y valores delta resultan en menos de la mitad del tamaño de almacenamiento descomprimido, entonces la compresión de color delta es exitosa y la información es almacenada en la mitad del tamaño (compresión 2:1).La GeForce GTX 1080 incluye la capacidad de compresión de color delta mejorada que ofrece:
    • La compresión 2:1 ha sido mejorada para que sea mas efectiva mas seguido.
    • Un nuevo modo de compresión 4:1 ha sido agregado para cubrir casos onde los pixeles deltas son muy pequeños y son posibles de empacarse en ¼ del tamaño original.
    • Un nuevo modo de compresión 8:1 combina la compresión constante de color 4:1 de bloques de 2×2 pixeles con compresión 2:1 de los deltas entre esos bloques.

    La siguiente captura de Project Cars muestra el beneficio de la compresión de color de Pascal. Las partes de la escena que pueden ser comprimidas son reemplazadas con magenta. Mientras que Maxwell era capaz de comprimir bastante de la escena, mucha de la vegetación y partes del auto no podían ser comprimidas. Con Pascal, muy poco deja de ser sin compresión.Como resultado de las mejoras en compresión de memoria, la GTX 1080 es capas de reducir significativamente el numero de bytes que tienen que ser extraídos de memoria por cuadro. Esta reducción en bytes se traduce en un 20% adicional de ancho de banda efectivo y cuando se le combina con la memoria GDDR5X, esto hace que se entregue un aumento de 1.7 veces el ancho de banda que entregaba la GTX 980.
    Computo Asincronico

    Actualmente, las cargas de trabajo en la jugabilidad son incrementalmente complejas, con múltiples-independientes, cargas de trabajo asincronicas, que, finalmente, trabajan en conjunto para contribuir a la imagen renderizada. Algunos ejemplos de computo asincronico son:
    • Procesamiento de audio y físicas basadas en GPU
    • Postprocesado de cuadros renderizados
    • Timewarp asincrónico, una técnica usada en VR para regenerar un frame final basado en la posición de la cabeza justo antes de el scanout de la pantalla, interrumpiendo el renderizado del siguiente cuadro para hacerlo.

    Estas cargas de trabajo asincronicas crean dos nuevos escenarios a considerar en una arquitectura de GPU.El primer escenario involucra sobreponer cargas. Ciertos tipos de cargas no llenan el GPU completamente por si mismas. En estos casos, hay una oportunidad de rendimiento para correr dos trabajos al mismo tiempo, compartiendo el GPU y haciendo que funcione mas eficientemente: por ejemplo, una carga de PhysX corriendo al mismo tiempo con un renderizado gráfico.Para cargas de trabajo sobrepuestas, Pascal introduce el soporte para “dynamic load balancing” o “balanceo de carga dinámico”. En Maxwell, las cargas de trabajo fueron implementadas con un particionado estático del GPU en un subset que corría gráficas y otro subset que corría computo. Esto es eficiente dado que el balance de trabajo entre dos cargas sean parecidas al ratio de particion. Sin embargo, si el computo toma mas que el flujo de carga gráfico, y ambos necesitan ser completados antes de que otro trabajo pueda ser efectuado y la porción de GPU configurada para correr gráficas se vaya a reposo. Esto puede causar desempeño reducido que puede exceder cualquier beneficio de desempeño que pueda haber sido entregado por correr cargas de trabajo sobrepuestas. El balanceo dinámico de carga por hardware soluciona este problema al permitir que las cargas de trabajo sean llenadas en el resto de la maquina si recursos en reposo están disponibles.Las cargas de trabajo de tiempo son el segundo escenario de computo asincronico importante. Por ejemplo, una operación asincronica timewarp debe completarse antes de que el scanout comience o un cuadro será botado. En este escenario, el GPU necesita soportar una anticipación rápida y de baja latencia para mover las cargas menos criticas fuera del GPU para que se muevan cargas mas criticas y que puedan ser ejecutadas lo mas rápido posible.Un solo comando de renderizado de un motor gráfico puede contener potencialmente cientos de llamadas de dibujo, con cada llamada de dibujo conteniendo cientos de triángulos, y cada triangulo conteniendo cientos de pixeles que necesitan ser sombreados y renderizados. Una implementación tradicional de GPU que implementa anticipación a un alto nivel en el flujo gráfico tendría que completar todo este trabajo antes de intercambiar tareas, resultando en un potencial retraso bastante largo.Para solucionar este problema, Pascal es la primera arquitectura de GPU en implementar Preempción (Anticipación) de nivel de Pixel. Las unidades gráficas de Pascal han sido mejoradas para mantenerse al tanto del progreso intermedio de trabajos de renderizado, para que cuando la anticipación sea solicitada, esas puedan detenerse donde están, guardar la información de contexto a cerca de donde comenzar nuevamente después y anticipar rápidamente. La ilustración siguiente muestra como una petición de anticipación siendo ejecutada.En el comando pushbuffer, tres llamadas de dibujo han sido ejecutadas, una esta en proceso y las otras dos están en espera. La llamada actual tiene seis triángulos, tres han sido procesados, uno esta siendo rasterizado y dos están esperando. El triangulo que se esta rasterizando esta a medio camino. Cuando una petición de anticipación es recibida, el rasterizador, sombreado de triángulos y procesador de comando pushbuffer se detendrán y guardaran su posición actual. Los pixeles que se han rasterizados terminaran de ser sombreados y luego el GPU estará listo para recibir una carga de alta prioridad. El proceso completo de intercambiar a una nueva carga de trabajo puede completarse en menos de 100 microsegundos (μs) después de que el trabajo de sombreado de pixeles sea terminado. Pascal también ha mejorado el soporte de anticipación para cargas de trabajo de computo. La ilustración de abajo muestra la ejecución de una carga de trabajo de computo.La preempcion (Anticipacion) de nivel de hilo para computo opera similar a lo que vimos anteriormente para gráficas. Las cargas de trabajo son compuestas por múltiples grillas e bloques de hilos, cada grilla contiene varios hilos. Cuando una petición de anticipación es recibida, los hilos que están actualmente corriendo en los SMs son completados. Otras unidades guardan la posición actual para preparase para cuando vuelvan a retomar lo que dejaron antes, y luego el GPU estará listo para nuevas tareas. El proceso completo de intercambiar a una nueva carga de trabajo puede completarse en menos de 100 microsegundos (μs) después de completar las tareas que se corren en el momento. Para cargas de trabajo de juego, la combinación de anticipación de nivel gráfico de pixeles y de nivel de computo de hilos le da a Pascal la habilidad de intercambiar cargas de trabajo de una manera bastante rápida.Para los computos CUDA, Pascal tambien es capaz de hacer anticipacion:En este modo de operación, cuando la petición de anticipación es recibida, todo el procesamiento de hilos se detiene en la instrucción actual y es intercambiada inmediatamente. Este modo de operación involucra substancialmente mas información de estados, por que todos los registros de cada uno de los hilos que se esta ejecutando, debe ser guardado. Esta es la forma mas robusta para la carga general de trabajos de computo de GPU que puedan tener tiempos de ejecución por hilo substanciales.Un ejemplo de una aplicación de anticipación en juego es el timewarp asincronico. El lado izquierdo de la ilustración muestra una operación timewarp asincronica con anticipación tradicional de GPU. El proceso ATW corre lo mas tarde posible antes del intervalo de refresco del monitor. Sin embargo, el trabajo ATW tiene que entregarse al GPU con muchos milisegundos de anticipación, por que sin una anticipación fina, hay una variación en el tiempo que le tome anticipar y comenzar la ejecución de ese proceso ATW. En la imagen de la derecha, con anticipación fina, (gráficas de nivel de pixel y ademas anticipación de nivel de hilo), el tiempo de anticipación es mucho mas rápido y determinante, así el trabajo ATW puede ser entregado mucho después mientas que se asegura su finalización antes que se cumpla el limite del refresco del monitor.Motor de Multi-Proyeccion Simultanea

    El bloque de Multi-Proyecction Simultanea es una nueva unidad de hardware, el cual esta ubicada dentro del motor PolyMorph al final del pipeline de geometria y justo en frente de la Unidad de Rasterizado. como su nombre lo dice, la unidad SMP es responsable de generar multiples proyecciones para un solo stream de geometría, mientas este entra al motor SMP por las etapas shader de mas arriba.El motor SMP es capaz de procesar geometrías a través de 16 proyecciones pre-configuradas, compartiendo el centro de la proyección (el punto de vista), y con hasta dos centros de proyección diferentes, offset a lo largo del eje X. Las proyecciones pueden ser independientemente movidas o rotadas en un eje. Dado que cada primitivo pueda mostrarse en múltiples proyecciones simultáneamente, el motor SMP entrega funcionalidad multi-cast, permitiendo a la aplicación instruirle al GPU que replique la geometría hasta 32 veces (16 proyecciones x 2 centros de proyección) sin la sobrecarga de aplicaciones adicionales ya que la geometría fluye por las lineas.En todos los escenarios, el procesamiento es acelerado por hardware, y el flujo de datos nunca deja el chip. Dado que la expansión de la multi-proyección sucede después del pipeline de geometría, la aplicación guarda todo el trabajo que de otra forma necesitaría para efectuarse en las etapas de shader de mas arriba . Los ahorros son particularmente importantes en escenarios de geometría pesada, como teselacion, donde correr el pipeline de proceso de geometría múltiples veces (una vez por cada proyección) seria muy costoso. En casos extremos, el motor SMP puede reducir la cantidad requerida de trabajo geométrico hasta 32x. Un ejemplo de aplicación SMP es el soporte optimo de pantallas surround. La forma correcta de renderizar pantallas surround es con diferentes proyecciones para cada uno de los tres monitores, haciendo calzar el angulo. Esto es soportado directamente en solo un paso por el SMP de Pascal, al especificar tres proyecciones separadas, cada una correspondiente al monitor apropiadamente ajustado. Ahora, el usuario tiene la flexibilidad de elegir el ajuste para sus monitores laterales y verá sus gráficas renderizadas con perspectivas geométricas correctas, con un mas amplo campo de visión (FOV). También hay que tener en consideración que una aplicación que utilice SMP para generar imágenes de pantalla surround debe soportar opciones FOV, y también utilizar llamadas API SMP para activar el FOV mas amplio.En los casos de que la superficie de proyección no pueda ser exactamente representada con un numero finito de proyecciones, el motor SMP de todas formas podrá entregar ganancias de eficiencia substanciales al generar una aproximación mas cercana a la superficie de proyección.Interfaz SLI Mejorada.

    Los entusiastas confían en que la tecnología SLI de NVIDIA les entregue la mejor de las mejores experiencias de juego a resoluciones y configuraciones al tope. Un ingrediente crítico en la tecnología SLI es el puente SLI, el cual es una interfaz digital que transfiere información de display entre las tarjetas GeForce instaladas en el sistema. Dos de estas interfaces han sido utilizadas históricamente para permitir comunicación entre tres o más GPUS (configuraciones 3Way o 4Way SLI).La segunda interfaz SLI es requerida para estos escenarios porque todos los GPUs necesitan transferir sus cuadros renderizados al monitor conectado al GPU maestro y en este punto cada interfaz se convierte en independiente.Comenzando con las GPUs de NVIDIA Pascal, las dos interfaces ahora se encuentran vinculadas para mejorar el ancho de banda entre GPUs. Este nuevo modo dual-link SLI permite que ambas interfaces SLI puedan ser utilizadas en tándem para alimentar una pantalla de alta resolución o múltiples pantallas en Surround.El modo Dual-Link SLI esta soportado con un nuevo puente SLI llamado SLI HB. Este puente facilita la transferencia de datos de alta velocidad entre GPUs, conectando ambas interfaces SLI. Esta es la mejor forma para lograr frecuencias completas SLI con las GPUs GeForce GTX 1080 corriendo en SLI. (Nota: la GeForce GTX 1080 es compatible con los puentes SLI anteriores, sin embargo, el GPU estará limitado a la máxima velocidad del puente que se utilice.Utilizando estos nuevos puentes SLI HB, la interfaz SLI de la GeForce GTX 1080 corre a 650MHz, comparada con los 400MHz que se encuentran en las GPUs GeForce anteriores que ocupan los antiguos puentes SLI. Sin embargo, los puentes antiguos funcionarán algo mas rápido cuando se utilicen con GPUs basadas en Pascal. Específicamente, puentes personalizados que incluyan iluminación LED ahora funcionaran a 650MHz cuando sean utilizados con una GTX 1080, tomando ventaja de la velocidad IO de Pascal.El nuevo sub-sistema SLI que se encuentra en la GeForce GTX 1080 entrega mas del doble del ancho de banda entre GPUs cuando se le compara con la interfaz SLI de las generaciones anteriores. Esto es particularmente importante para altas resoluciones como 4K, 5K y surround. Ya que la GeForce GTX 1080 ahora soporta diferentes tipos de puentes, es importante saber que puentes funcionan mejor dependiendo la necesidad. Abajo se encuentra una tabla con las configuraciones recomendadas:Con el ancho de banda adicional entregado por la nueva interfaz SLI y el puente SLI HB, el SLI de GeForce GTX 1080 entregará a los gamers una experiencia de juego aun mas fluida comparada con las soluciones anteriores SLI como se muestra en el gráfico a continuación:
    Tiempos de Cuadros por segundo con una GeForce GTX 1080 corriendo Shadow of Mordor a 11520×2160 con el nuevo puente SLI HB (en azul) vs el viejo puente SLI (en negro). Los peaks mas largos del puente viejo indican stuttering.
    Nuevos modos Multi GPU

    Comparado con APIs anteriores de DirectX, Microsoft ha hecho un gran numero de cambios que tienen impacto en la funcionalidad de Multi-GPU en DirectX 12. En el nivel mas alto, hay dos opciones básicas para que los desarrolladores utilicen multiGPU en hardware NVIDIA con DX12:
    • Multi Display Adapter (MDA)
    • Linked Display Adapter (LDA)

    El modo LDA tiene dos formas: Implicit LDA Mode, el cual NVIDIA utiliza para el SLI, y Explicit LDA Mode, donde los desarrolladores de juegos manejaran la responsabilidad necesaria para que la operación de multiGPU funcione exitosamente. Los modos MDA y LDA han sido desarrollados para entregarle mas control a los desarrolladores mas control.La siguiente tabla resume los tres modos soportados en GPUs NVIDIA:En modo LDA, cada memoria de los GPUs puede ser vinculada completamente para ser un gran banco de memoria para el desarrollador (aun que hay algunas excepciones); sin embargo, hay una penalización de desempeño si la información necesita ser ubicada en la memoria de otro GPU, dado que la memoria se accede a través del interior del GPU en comunicación peer-to-peer (como PCIe). En el modo MDA, cada memoria de cada GPU es utilizada independientemente: cada GPU no puede acceder directamente a la memoria del otro.El modo LDA es destinado para el uso de multo-GPU en sistemas que tienen GPUs similares a si mismas, mientras que el modo MDA tiene menos restricciones – GPUs discretas pueden ser pareadas con GPUs integradas, o GPUs discretas de otros fabricantes- pero el modo MDA requiere que el desarrollador tenga mucho mas cuidado al manejar todas las operaciones necesarias para que los GPUs se comuniquen entre si.Por defecto el SLI de GeForce GTX 1080 soporta hasta dos GPUs. Los Modos 3-Way y 4-Way SLI ya no serán recomendados. Como los juegos han evolucionado, se ha convertido en algo bastante difícil que estos modos SLI entreguen un desempeño beneficial de escalado para los usuarios. Por ejemplo, muchos juegos se quedaban cortos de CPU al generarse un cuello de botella cuando se corrían en los modos 3-Way o 4-Way SLI, y los juegos están constantemente utilizando técnicas que hacen muy difícil la extracción de paralelismo cuadro-a-cuadro. Ahora, los sistemas aun pueden ser construidos con modos Multi-GPU por software incluyendo:
    • MDA o LDA Explicit
    • 2-Way SLI + un GPU para PhysX.

    Llave entusiasta

    Si bien NVIDIA no recomienda los modos 3-Way o 4-Way SLI, todos sabemos que los entusiastas no se quedaran tranquilos… de hecho, algunos juegos seguirán entregando gran escalabilidad mas allá de dos GPUs. Para esta clase de usuarios, se ha desarrollado una “Llave Entusiasta” o “Enthusiast Key” la cual puede ser descargada desde la pagina de NVIDIA y ser cargado para cada GPU. El proceso involucra:
    1. Correr la app localmente para generar la firma de tu GPU
    2. Pedir la Enthusiast Key en el sitio web de entusiastas de NVIDIA
    3. Bajar la llave
    4. Instalar la llave para desbloquear la función 3-Way y 4-Way SLI.

    Los detalles de este proceso estarán disponibles eventualmente en el sitio web de NVIDIA cuando los GPUs GTX 1080 esten en las manos de los usuarios.Fast Sync

    Fast Sync es una alternativa, consciente a la latencia, al Vertical Sync o V-SYNC, que elimina el tearing, mientras permite al GPU renderizar sin restricciones de refresco para reducir latencia.Cuadros Renderizados – Metodo tradicional

    Esta es un gráfico básico de como la renderización de cuadros funciona en un pipeline de gráficas NVIDIA:El motor del juego es el responsable de generar los cuadros que son enviados a DirectX. El motor del juego también calcula el tiempo de animación; la codificación del cuadro que eventualmente se renderizará. Las llamadas de dibujo e información son comunicadas, el driver de NVIDIA y el GPU las convierten en renderizado, y luego se escupe el cuadro renderizado al frame buffer del GPU. El ultimo paso es escanear el cuadro a la pantalla. Ahora, estamos haciendo las cosas algo diferentes en Pascal.Juegos de altos FPS (Frames-Per-Second)

    Juegos de altos FPS, como Counter-Strike: Global Offensive, se corren a muchos cuadros por segundo el día de hoy en Pascal. La pregunta es: ¿que de bueno es esto?. El día de hoy, hay dos opciones para mostrar el juego: con V-SYNC ON o con V-SYNC OFF.

    Si utilizas V-SYNC ON, el pipeline se presuriza hasta el motor del juego y el pipeline completa se ralentiza a la frecuencia de refresco del monitor. Con V-SYNC ON, el monitor básicamente le dice al motor del juego que se relaje, solo por que un solo cuadro se puede ser generado por cada intervalo de refresco del monitor. La ventaja de V-SYNC ON es la eliminación del tearing, pero la desventaja es la latencia. Cuando utilizamos V-SYNC OFF, se le dice a la pipeline que ignore la frecuencia de refresco del monitor y que entregue los cuadros del juego lo mas rápido posible. La ventaja de V-SYNC OFF es baja latencia (ya que no hay presión), pero la desventaja es el tearing. Estas son las opciones que tienen los gamers actualmente y la mayoría de los gamers de eSports juegan con V-SYNC OFF para tomar ventaja de la baja latencia, dándoles una ventaja competitiva. Desafortunadamente, el tearing a altos FPS causa jittering, el cual puede estorbar su juego.Decoupled Render y Pantalla

    NVIDIA ha tomado otra mirada a como el proceso tradicional funciona y, por primera vez, el renderizado y el monitor han sido desvinculados de la pipeline. Esto permite que la etapa de renderizado continuamente genere nuevos cuadros de la información enviada por el motor del juego y driver a velocidad completa, y esos cuadros pueden ser almacenados temporalmente en el frame buffer del GPU.Cuadros Renderizados – FAST SYNC

    NVIDIA ha desvinculado el comienzo de la pipeline de renderizado desde el backend del hardware del monitor. Esto permite muchas formas para manipular el monitor y esto puede entregar nuevos beneficios a los gamers. Fast Sync es una de las primeras aplicaciones de esta propuesta. Con Fast Sync, no hay control de flujo. El motor del juego funciona como si el V-SYNC estuviera desactivado. Y, como no hay presión trasera, la latencia es tan baja como si el V-SYNC estuviera en OFF. Lo mejor es que , no hay tearing, ya que Fast Sync elige que cuadros renderizados terminaran en el monitor. Fas Sync permite que el frente de la pipeline corra lo mas rápido que pueda, y que determine la cantidad de cuadros que se enviaran al monitor, mientras que simultaneamente preservará cuadros enteros para que sean mostrados sin tearing.

    La experiencia que FAST SYNC entrega, dependiendo del frame rate, es casi igual a la claridad del V-SYNC on combinado con la baja latencia de V-SYNC OFF.Buffers DesacopladosUna forma para pensar sobre Fast Sync es imaginar que tres áreas en el mismo frame buffer han sido ubicadas en tres formas diferentes. Los dos buffers primarios son bastante similares a un VSYNC de doble buffer en las pipelines clásicas de GPU. El Buffer Frontal (FB) es el buffer escaneado hacia la pantalla. Esta es una superficie completamente renderizada. El Buffer Trasero, es el que actualmente se está renderizando y no puede ser escaneado hasta que se complete. Usando el VSYNC tradicional en juegos de alto renderizado, no es bueno para la latencia, dado que el juego debe esperar al intervalo de refresco para dar vuelta el buffer trasero para que se convierta en buffer frontal antes de que otro cuadro pueda ser renderizado en el buffer trasero. Esto ralentiza todo el proceso y agregar buffers traseros solo agrega mas latencia, dado que estos podrían llenarse rápidamente por el renderizado de alta demanda, causando pausas en el motor del juego. Fast Sync introduce un tercer buffer llamado Ultimo Buffer de Renderizado (Last Rendered Buffer o LRB) el cual se utiliza para mantener todos los nuevos cuadros renderizados que se completaron en el Buffer Trasero – en efecto, haber tenido copia mas reciente del buffer trasero – hasta que el buffer delantero haya terminado de escanearse, al punto de que el Ultimo Buffer Renderizado es copiado al buffer frontal y el proceso continua. Las copias actuales del buffer serian ineficientes, así que los buffers son solo renombrados. El buffer que se esta escaneando a la pantalla es el FB, el buffer que se esta renderizando activamente es el BB y el buffer almacenando la copia mas reciente es el LRB. La nueva lógica de cambios en la arquitectura Pascal controla el proceso completo. El proceso típico se vería de la siguiente forma:
    • Escanear de FB
    • Renderizar a BB
    • Cuando el renderizado se completa
      • BB se convierte en LRB
      • LRB se convierte en BB y el renderizado continua

    • Cuando el renderizado se completa
      • BB se convierte en LRB
      • LRB se convierte en BB y el renderizado continua

    • Cuando el renderizado se completa
      • BB se convierte en LRB
      • LRB se convierte en BB y el renderizado continua

    • Cuando el escaneo se completa
      • LRB se convierte en FB

    • Comienza a escanear desde un nuevo FB

    Resultados de latencia Fast Sync

    Los datos son convincentes. La latencia es alta con V-SYNC ON. Los gamers de juegos de altos FPS utilizan V-SYNC OFF para tener la mejor respuesta en sus juegos, mientras que pelean con jitter causado por el tearing a altas tasas de cuadros por segundos. Activar Fast Sync entrega ~8ms mas de latencia que V-SYNC OFF, mientras que entrega cuadros completos sin problemas como tearing o jitter.HDR

    Los nuevos monitores HDR (High Dynamic Range) proveen uno de las grandes ventajas en la calidad de pixeles en monitores en los últimos 20 años. El gamut de color BT.2020 cubre hasta el 75% de los colores visibles (hasta un 33% para sRGB) – un aumento de dos veces en el rango de colores. En adición, se estima que los monitores HDR entreguen un peak de brillo mas alto (con paneles LCD sobre los 1000 nits) y una gran relación de contraste (>10:000 a 1).Con un mayor rango de brillo y colores mas saturados, el contenido HDR imita de forma mas cercana el mundo real: negros mas intensos, y blancos mas brillantes. Variaciones adicionales en el color producen imágenes mas vivas que resaltan: los usuarios finalmente ven el rojo y naranjo en el fuego o una explosión, en vez de verse todo mezclado. Y por que los monitores HDR soportan relaciones de contraste mas altas, los usuarios verán mas detalles en las áreas de escenas claras y oscuras cuando se le compara al SDR que viene en los monitores actuales.La GeForce GTX 1080 soporta todas las capacidades HDR que tenia Maxwell. El controlador de pantalla es capaz de color 12b, color gamut BT.2020 amplio, SMPTE 2084 (Perceptual Quantization), y HDMI 2.0b 10/12b para 4K HDR. En adición, Pascal introduce nuevas características como:[email protected] 10/12b HEVC Decode (para HDR Video)
    [email protected] 10b HEVC Encode (para grabacion HDR o streaming)
    – DP1.4-Ready HDR Metadata Transport (para conectar monitores HDR utilizando DisplayPort)
    Televisores HDR están disponible hoy, y las características mencionadas anteriormente permitirá que los usuarios puedan disfrutar juegos HDR en sus televisores HDR incluso si su PC no esta conectado directamente al TV, utilizando HDR GameStream, que estará disponible en el futuro cercano.NVIDIA está trabajando con los desarrolladores de juegos para traer HDR a los juegos de PC. NVIDIA le entregará a los desarrolladores APIs y soporte de drivers así como también las guías necesarias para renderizar adecuadamente imágenes HDR que sean compatibles con los nuevos monitores HDR. Como un resultado de este esfuerzo, se vienen próximamente juegos que soportan HDR como Obduction,The Witness, Lawbreakers, Rise of the Tomb Raider, Paragon, The Talos Principle y Shadow Warrior 2.

    https://www.ozeros.com/2016/05/anali...-la-velocidad/

  8. #48
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Arquitectura AMD ‘Polaris’ al detalle

    Las nuevas gpus de AMD bajo la arquitectura ‘Polaris‘ por fin están entre nosotros, y tras analizar el rendimiento de la RX 480, vamos a enfocar éste artículo desde un punto de vista más técnico, alejados de las tradicionales tablas comparativas, números y rendimientos que tan acostumbrados estamos.
    No vamos a enrollarnos en exceso y vamos a desglosar este artículo en varias partes. La primera y más importante veremos el nuevo esquema GCN 4.0 con el diagrama de la RX480, hablaremos de su front-end y las modificaciones que ha sufrido, las partes intermedias como Shaders, controladores de memoria etc y finalmente las partes menos importantes pero que poseen su relevancia. Demos comienzo…
    Diagrama de RX480. ‘Polaris’ en todo su esplendor.

    Tan solo con echar un vistazo, no podemos evitar tener en mente una de las gpus relevantes de la anterior gama media, la R9 380/380X, pues éste esquema es tremendamente similar en composición y ubicación a los elementos que componen la nueva ‘Polaris’.
    Mucho se ha discutido acerca del cómputo asíncrono pero todo indica que irá cobrando aun más protagonismo con la realidad virtual (VR en adelante) así como las apis de bajo nivel (Directx 12 y Vulkan), pero éste es otro tema que no venimos a tratar sino que novedades trae ‘Polaris’ y que tendremos con ellas.
    Te recomendamos la lectura de nuestra guía de mejores tarjetas gráficas.
    El nuevo esquema del front-end dispone de 4 motores de cómputo asíncrono (ACEs) y dos nuevas unidades HWS (Hardware Scheduler), o traducido a nuestro idioma, programadores de hardware.
    Los HWS tendrán Shaders disponibles en todo momento para una tarea concreta, siendo ésta la que más prioridad tenga en acceder a esos Shaders. Este completo y complejo funcionamiento resulta de vital importancia para las nuevas apis de bajo nivel (DX12 y Vulkan) o para la VR ya que era muy difícil garantizar los recursos disponibles complicando las labores de cómputo, como por ejemplo para el procesamiento de audio, planificar procesos y gestionar el balance de recursos entre tareas de cálculo y gráficos reduciendo la dependencia de la CPU. Cada una de éstas unidades puede acceder a la totalidad de la gpu de forma individual.

    A estas nuevas unidades se accede vía microcódigo, es decir que son programables pudiendo AMD actualizar su funcionamiento. Paulatinamente irán llegando juegos o software que lo soporten y sean los programadores los aprovechen sus características. Estas unidades están disponibles en la 480, 470 e incluso la 460 sin recortes.
    Compute Units y Motores de Geometría.

    El sistema de Shaders por Compute Unit sigue siendo el mismo, 64 Shaders por cada uno de ellos. En la RX480 tenemos un esquema de 36 CUs dando un total de 2304 Shaders en total.


    Las mejoras que tenemos son principalmente en las caches y en el prefetch (prelecturas) haciendo el almacenamiento de instrucciones más eficiente. La cache nivel 2 ha ascendido de 768Ks a 2Mb y además de ser más eficiente de acceder ahora también se puede agrupar.
    El buffer para guardar las oleadas de instrucciones es mucho mayor, y es el que está a la espera de tareas. Y como novedad tenemos la capacidad nativa de ejecutrar operaciones Fp16 e Int16. Respecto a la arquitectura Hawaii, AMD nos dice que tenemos hasta un 15% más de rendimiento por bloque sobre ésta con Polaris.

    Por fin, una de las mejoras más esperadas viene de los motores de geometría. Trae consigo el nuevo ‘Primitive Discard Accelerator‘. Esta unidad tiene la simple tarea de no cargar la geometría que está detras de un objeto o que es lo suficientemente pequeña como para no ser visible, usando su pipeline para descartar rápidamente las tareas que no serán útiles por otras que si lo serán beneficiando siempre la experiencia del usuario, es decir ganando en eficiencia y rendimiento.
    Fijándonos en la imagen de más arriba, vemos como se ha añadido un ‘Index Cache’, que básicamente es una pequeña cantidad de memoria para geometría de instancia, es decir para objetos o cosas que se repiten en pantalla una y otra vez, evita que se recurra a la memoria cache L2 pudiendo almacenar de forma local esa información ganando de nuevo en eficiencia y ancho de banda de memoria.
    Memoria y Delta Color Compression.

    Tal y como sucedió con la veterana R9 285, se estrenó un sistema de compresión de color para así ahorrar ancho de banda de memoria, técnica ideal para gpus con ‘poco’ ancho de banda o no tan grande como en modelos superiores.
    La nueva RX 480 dispone de un total de 256Gb/s de ancho de banda, cifra bastante superior a las encontradas dentro de su mismo segmento en las pasadas generaciones, como la 380X que rondan los 180Gb/s pero que a su vez es una cifra inferior a la 290 donde AMD nos indica que ‘Polaris’ es más eficiente y posee un ancho de banda en la práctica más efectivo debido al aumento de ancho de banda y la compresión de color. Esta diferencia llegaría hasta un 40% de ahorro de energía de acuerdo con AMD.
    Esto es debido al aumento de memoria cache L2 y de su nuevo proceso de fabricación en 14nm Fin Fet pero realmente es por su nuevo sistema de compresión, teniendo un ratio de 2/4/8:1. Cada vez que pueden ser comprimidos los datos, éstos se almacenan en la cache en menor medida ahorrando energía, además de ser compatible con altas cantidades de memoria como los 8Gb gDDR5 que posee.
    Conectividad y vídeo.

    Tanto la arquitectura de Nvidia ‘Pascal’ como la nueva ‘Polaris’ de AMD han puesto al día toda la conectividad de sus tarjetas, disponiendo de hasta 3 puertos DisplayPort y un HDMi 2.0 rev.B compatible con vídeo HDR (High Dynamic Range), un ancho de banda disponible de hasta 18Gbps y con una resolución máxima de [email protected], resolución 4 veces mayor que el estándar actual.
    En cuanto a audio es capaz de sacar 32 canales para una mayor inmersión espacial.
    Los DisplayPorts se actualizan a la versión 1.4 para garantiar un mejor color utilizando Display Stream Compression y llevar así altísimas resoluciones como 8K con una tasa de refresco de hasta 60Hz y llevando los 120Hz a pantallas 4K con soporte HDR.
    Toda la gama ‘Polaris’ soporta HDR, algo realmente importante para mostrar mejores píxeles, un rango de color más amplio y contraste. A lo largo de 2016 y sobre todo 2017 irán llegando al mercado monitores y TV con soporte para ésta tecnología, de caracter importante sobre todo para los amantes del cine ya que el estándar Ultra HD Bluray llegará junto a ellos siendo también compatible con HDR.
    No sólo los cinéfilos disfrutarán de ésta tecnología sino que también llega para los gamers más exigentes!.
    En resumen, tenemos una puesta al día de la más que conocida y todoterreno arquitectura Graphic Core Next, actualizando las partes más críticas como las unidades de geometría que se encargan del teselado, las unidades HWS más precisas para cómputo asíncrono en lugar de poner tantos ACEs así como ahorrar en ancho de banda. Es una gpu con mucho potencial y un precio asequible para lo que suelen ser éste tipo de tarjetas, que empezaremos a ver próximamente el auténtico desempeño de la misma con drivers maduros que puedan sacar partido a las tecnologías aquí descritas y la llegada masiva de modelos ‘custom’.

























































    Estos son los apartados que más nos han gustado y esperamos que muchas de las incógnitas os queden resueltas, pero os dejamos una galería de imágenes con toda la presentación de la arquitectura para que tengáis mayor detalle de lo analizado hasta aquí.
    Recuerda puedes dar tu opinión a nuestra review de la AMD Radeon RX 480, el nuevo bombazo de AMD en tarjetas gráficas de gama media y alta.
    ¡Hasta pronto!


    Más información en: https://www.profesionalreview.com/20...is-al-detalle/

    Más información en: https://www.profesionalreview.com/20...is-al-detalle/

  9. #49
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Async ON OFF en Tyme Spy


  10. #50
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Otro tipo de tecnicas

    Cita Iniciado por stalker77
    Sobre Quatum Break y la GI, en realidad no usa Voxel, al parecer sigue siendo una técnica muy costosa, esto tenían planeado para GI:

    Solucion 1:

    Dynamic Approaches
    — Virtual Point Lights (VPLs) [Keller97]
    — Light Propagation Volumes [Kaplaynan10]
    — Voxel Cone Tracing [Crassin11]
    — Distance Field Tracing [Wright15]

    Solucion 2

    Mesh-based Precomputation
    — Precomputed Radiance Transfer (PRT) [Sloan02]
    — Spherical Harmonic Light Maps
    Meshless Precomputation
    — Irradiance Volumes [Greger98]

    Lo que terminaron usando, para un bajo coste:

    Meshless Precomputation
    — Irradiance Volumes [Greger98]

    Creo esta técnica es la que utiliza Crysis 3 o el Cryengine, solo que en estos se conoce como Light Propagation Volumes:



    http://foro.noticias3d.com/vbulletin...38117&page=662

    Parche de Deus Ex para dx12, que supuestamente corrige estos aspectos :

    -Se ha corregido un accidente de DirectX 12 en el arranque.
    -uso de la CPU DirectX 12 reducida para un mejor rendimiento.
    -Ligeramente reducido el uso de memoria del sistema.

    Traducido desde Google.

    - - - Actualizado - - -

    Un test de CPU y no se que análisis se puede sacar de algo asi:

    Dx11 800*600 (para generar cuello) GPU: 70% de carga y CPU: 100% 4 nucleos:



    DX12 800*600 (para generar cuello) GPU: 94% de carga y CPU: 92% 4 nucleos:



    La verdad no entiendo, en Dx12 el cuello se reduce, con menor uso del CPU y mayor carga de la GPU, pero en FPS sigue rindiendo peor, al menos que el medidor este midiendo mal en Dx12 deberia de ir mucho mejor en FPS que en Dx11, estamos hablando que en dx12 la carga de GPU es de 94% vs los 70% de dx11.
    Volviendo hacer un poco de offtopic, el todo poderoso crysis 3 haciendo uso de sombras (sombras de mapeo) de 1024, al final cuando comienzas a profundizar todos los juegos cogean de alguna parte, aparte que muchos efectos punteros te los dan a cuenta gotas, hace falta mucha potencia todavía para ver un juego donde no recorten mucho, pero al final también es parte de la optimizacion "te agrego esto, pero te quito por este lado".....

    Mapeo de sombras a 1024 resolucion(valor máximo del juego):



    Mapeo de sombras 4096 resolucion (modificado):



    Un Bonus a 8192:



    TW3 en Ultra usa 3072 y creo que maneja mas sombras, como se puede obserbar el impacto el rendimiento es notorio, en algo tenían que optimizar con iluminación Indirecta y definición de sombra de ps3.
    Última edición por Activity; 02/10/2016 a las 03:02

  11. #51
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    DOOM (2016) - Graphics Study


    DOOM fue pionera en cambios fundamentales en el diseño del juego y la mecánica en 1993, fue un fenómeno mundial, que condujo a la fama figuras icónicas como John Carmack y John Romero ...
    23 años después, id Software pertenece ahora a Zenimax , todos los fundadores originales se han ido pero no impidió que el equipo de Identificación de mostrar todo su talento mediante la entrega de un gran juego.

    El nuevo DOOM es un complemento perfecto para la franquicia, utilizando el nuevo motor id Tech 6 , donde ex Crytek Tiago Sousa ahora asume el papel de programador procesador de plomo después de la salida de John Carmack.
    Históricamente id Software es conocido por open-sourcing sus motores después de una pocos años, que a menudo conduce a
    buenos remakes y averías . Si esto va a soportar cierto con id Tech 6 queda por ver, pero que no necesariamente tienen el código fuente para apreciar las buenas técnicas gráficas aplicadas en el motor.

    ¿Cómo se representa un marco

    Vamos a examinar la escena de abajo donde el jugador ataca a un nido Gore defendida por algunos Possessed enemigos, justo después de la obtención de la Suit pretor en el comienzo del juego.

    A diferencia de la mayoría de los juegos de Windows en libertad en estos días, DOOM no utiliza Direct3D , pero ofrece una OpenGL y Vulkan backend.
    Vulkan ser la nueva cosa caliente y
    Baldur Karlsson que recientemente ha añadido soporte para él en RenderDoc , se resiste a recoger en partes internas DOOM duro. Las siguientes observaciones se basan en el juego funcionando con Vulkan en una GTX 980 con todos los ajustes en Ultra , algunos son conjeturas que otros se toman de la presentación Siggraph de Tiago Sousa y Jean Geffroy .

    Mega-textura de actualización

    El primer paso es el Mega-Textura actualización, una técnica ya presente en el id Tech 5 usado en RAGE y ahora también se utiliza en DOOM.
    Para dar una explicación muy básica, la idea es que un par de texturas enormes (16k x 8k en Doom) son asignada en la memoria de la GPU, siendo cada uno de éstos una colección de 128x128 azulejos.


    16k x 8k de almacenamiento con 128 x 128 páginas

    Todas estas baldosas se supone que representan el conjunto ideal de texturas reales en el buen nivel mipmap que serán necesarios por los sombreadores de píxeles más adelante para hacer que la escena en particular que está viendo.
    Cuando el sombreado de píxeles lee de una "textura virtual" se simplemente termina la lectura de algunos de estos 128x128 azulejos físicas.
    por supuesto, dependiendo de donde el jugador está mirando, este conjunto va a cambiar: nuevos modelos aparecerán en la pantalla, haciendo referencia a otras texturas virtuales, nuevas baldosas deben ser escuchados en, viejo los transmiten a cabo ...
    Así que al comienzo de una trama, DOOM actualiza algunos azulejos a través vkCmdCopyBufferToImagede traer algunos datos reales de textura en la memoria de la GPU.
    Más información sobre Mega-Texturas aquí y aquí .
    Sombra Mapa Atlas

    Para cada luz una sombra, un único mapa de profundidad se genera y se guarda en una baldosa de un gigante 8k x 8k atlas de la textura . Sin embargo no todos los sola mapa de profundidad se calcula en cada cuadro: DOOM en gran medida re-utiliza el resultado de la trama anterior y regenera sólo los mapas de profundidad, que necesitan ser actualizados.

    8k 8k x Profundidad Buffer
    (Cuadro anterior)




    8k 8k x Profundidad Buffer
    (fotograma actual)





    AnteriorSiguiente

    • 1
    • 2


    Cuando una luz es estática y arroja sombras sólo en objetos estáticos que tiene sentido para simplemente mantener su mapa de profundidad tal cual en vez de hacer nuevos cálculos innecesarios. Si algún enemigo se mueve bajo la luz, sin embargo, el mapa de profundidad se debe generar de nuevo.
    Tamaños mapa de profundidad pueden variar en función de la distancia de la luz de la cámara, también mapas de profundidad re-generados no necesariamente permanecen dentro de la misma baldosa en el atlas .
    el destino tiene optimizaciones específicas como el almacenamiento en caché de la parte estática de un mapa de profundidad, la computación entonces sólo la dinámica mallas proyección y composición de los resultados.
    Profundidad Pre-Pass

    Todas las mallas opacas se visualizan ahora, sólo su salida a la información de profundidad en un mapa de profundidad.Primera arma del jugador, entonces la geometría estática y la geometría finalmente dinámico.

    Mapa de profundidad: 20% progresar



    Mapa de profundidad: 40% progresar



    Mapa de profundidad: 60% progresar



    Mapa de profundidad: 80% progresar



    Mapa de profundidad: 100% progresar




    AnteriorSiguiente

    • 1
    • 2
    • 3
    • 4
    • 5


    Pero en realidad la profundidad no era la única información emitida durante la pre-pase profundidad.
    Si bien los objetos dinámicos (los poseídos , cables, arma del jugador) se prestaron al mapa de profundidad, su velocidad por píxel, también se calculó y se escriben en otro búfer para crear un mapa de la velocidad. Esto se hace mediante el cálculo en el vertex shader la diferencia de posición de cada vértice entre el anterior y el actual.

    Mapa de velocidad

    Tan sólo hay 2 canales para almacenar la velocidad: el rojo es la velocidad a lo largo del eje horizontal y verde a lo largo del eje vertical.
    El Possessed se está moviendo rápidamente hacia el jugador (verde), mientras que el arma está apenas se movía (negro).
    ¿Qué pasa con el amarillo área (rojo y verde ambos iguales a 1)? En realidad es el color original por defecto de la memoria intermedia, que ninguna malla dinámica jamás tocó: esto es todo el "área de malla estática" .
    ¿Por qué omitir DOOM el cálculo de la velocidad de mallas estáticas? Debido a una velocidad de píxeles estática, simplemente se puede deducir de su profundidad y la cámara del jugador nuevo estado desde la última trama, no hay necesidad de calcular en función de cada malla.
    El mapa de velocidad será útil más tarde para aplicar un poco de
    desenfoque de movimiento .

    Las consultas de oclusión


    Prueba de la Caja
    Roja: ocluido
    Verde: Visible



    Queremos enviar tan poco de geometría para representar a la GPU como sea posible así que la mejor manera de lograr esto es a sacrificar todas las mallas que no son directamente visibles por el jugador. La mayor parte de la eliminación selectiva de oclusión en Doom se realiza a través del middleware Umbra , pero todavía hay algunas consultas GPU de oclusión realizadas por el motor para recortar más abajo en el conjunto de la visibilidad.
    ¿Cuál es la idea detrás de la GPU consultas de oclusión?
    El primer paso es agrupar varias mallas del mundo en una caja virtual que abarca a todos, a continuación, pedir a la GPU para hacer esta caja frente al tampón de profundidad actual. Si ninguno de los píxeles rasterizadas pasa la prueba de la profundidad significa que el recipiente está completamente ocluido y todos los objetos del mundo dentro de esa caja se puede omitir de forma segura en la representación.
    Bueno, la cosa es que estos resultados de la consulta de oclusión no están disponibles de inmediato, don 't desea detener el oleoducto GPU mediante el bloqueo en una consulta. Por lo general, la lectura de los resultados se difiere para las siguientes tramas, por lo que es necesario contar con un algoritmo de un conservador poco para evitar los objetos estallar.

    Agrupado-Forward-Rendering de objetos opacos

    Toda la geometría opaco y las calcomanías ahora son prestados. La información almacenada en la iluminación está un flotador HDR tampón:

    Iluminación 25%



    Iluminación 50%



    Iluminación 75%



    Iluminación 100%




    AnteriorSiguiente

    • 1
    • 2
    • 3
    • 4


    La función de prueba de profundidad se fijan para EQUALevitar cualquier cálculo de descubierto por inútil, gracias a la pre-pase profundo anterior que saben exactamente qué valor de profundidad de cada píxel se supone que tiene.
    Las etiquetas también son aplicadas directamente cuando se prestan mallas, sino que están almacenados en una textura del atlas.
    Ya se ve bien, pero todavía se está perdiendo algunos materiales transparentes como el cristal, o de partículas y no hay ambiente de reflexión en absoluto todavía.
    Unas palabras acerca de este paso: Utiliza un procesador de avance en clúster que se inspira en Emil persona de y de Ola Olsson . Trabajo
    históricamente una de las debilidades de la representación hacia adelante fue su incapacidad para manejar un gran número de luces, algo mucho más fácil de manejar en diferido .
    Entonces, ¿cómo funciona un procesador agrupado
    Bueno, primero se divide la ventana gráfica en baldosas: DOOM crea una subdivisión de 16 x 8. Algunos de render se detendría aquí y calcular una lista de las luces por baldosas que ayuda a reducir la cantidad de cálculos de iluminación, pero todavía sufre de algunos casos extremos.

    Frustum cámara agrupado


    Representación agrupado lleva el concepto aún más, de 2D a 3D: en lugar de detenerse en una subdivisión ventana gráfica 2D, que en realidad realiza una subdivisión 3D de todo el tronco de la cámara mediante la creación de rebanadas a lo largo del eje Z.
    Cada "bloque" se llama un "cluster", también se podría llamar "forma de cono truncado" voxels .
    A la derecha está un poco de la visualización de una simple ventana gráfica 4 x 2 subdivisión, con 5 rebanadas de profundidad dividir el tronco en 40 grupos.

    En DOOM el tronco de la cámara se divide en grupos de 3072 (una subdivisión de 16 x 8 x 24), las rebanadas de profundidad estando posicionados de manera logarítmica a lo largo del eje Z.
    Con un procesador de clúster, un flujo típico sería:

    • En primer lugar la CPU calcula la lista de elementos que influyen en la iluminación interior de cada grupo: luces, calcomanías y cubemaps ...
      Para ello todos estos elementos son "voxelized" por lo que su área de influencia se puede verificar si forma intersección con racimos. Los datos se almacenan como listas indexadas en tampones GPU de manera que los shaders pueden acceder a él.Cada grupo puede contener hasta 256 luces, 256 calcomanías y 256 cubemaps.
    • Luego, cuando la GPU hace un píxel:
      • a partir de las coordenadas de píxeles y la profundidad, el grupo al que pertenece se determina
      • la lista de las etiquetas / las luces de este grupo específico se recupera. Se trata de compensar indirecto y cálculo de índice como se ilustra a continuación.
      • el código de bucles sobre todas las etiquetas / luces de la agrupación, el cálculo y la adición de su contribución.


    Aquí es en realidad cómo el sombreado de píxeles puede recuperar la lista de luces y gráficos durante este paso:

    La aplicación de las luces y calcomanías - # 1



    La aplicación de las luces y calcomanías - # 2



    La aplicación de las luces y calcomanías - # 3



    La aplicación de las luces y calcomanías - # 4



    La aplicación de las luces y calcomanías - # 5



    La aplicación de las luces y calcomanías - # 6




    AnteriorSiguiente

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6


    También está la lista de sondeo (no se muestra en el diagrama anterior) que se puede acceder exactamente de la misma manera, pero no se utiliza en este paso por lo que pondremos en contacto con él más tarde.
    La sobrecarga de pregenerating una lista de artículos por racimo en la CPU es bien vale la pena teniendo en cuenta la forma dramática que puede cortar la complejidad de cálculo de representación en la GPU en la línea.
    clúster de avance de representación está recibiendo algo de atención recientemente: tiene la propiedad agradable de manejar más luces que avance básica mientras que ser más rápido que diferidos, que tiene que escribir / leer de varios G-buffers .
    Pero hay algo que no he mencionado todavía: este paso que acabamos de examinar no es simplemente un uno delante de grabar en un tampón de iluminación; mientras que se llevó a cabo 2 delgada G-buffers también se generaron usando MRT :
    El mapa normal se almacena en un formato de flotador R16G16 . El mapa es especular en R8G8B8A8 , el canal alfa contiene el factor de suavidad.
    Así DOOM realidad hábilmente mezcla hacia adelante y diferida con un enfoque híbrido. Estos extras G-buffers será muy útil al realizar efectos adicionales como reflexiones.
    Y lo último que omitido: un tampón de retroalimentación 160 x 120 para el sistema de mega-textura también se genera en el mismo tiempo. Contiene información para indicar al sistema de streaming, que las texturas en la que MIPmap nivel debe ser transmitido de entrada.
    El motor de mega-textura funciona de una manera reactiva: es después de la pasada rinden informes ciertas texturas faltan que las cargas del motor ellas.
    Las partículas de la GPU

    Un shader de cómputo es enviado a actualizar la simulación de partículas:. La posición, velocidad y tiempo de vida
    Se lee los estados de las partículas actuales, así como la memoria intermedia de la normalidad y la profundidad (para la detección de colisiones), desempeña un paso de simulación y almacena respaldan los nuevos estados en búferes .

    Oclusión del ambiente en pantalla


    SSAO Mapa


    En este paso la SSAO mapa se genera ahora.
    Su propósito es para oscurecer el color alrededor de las costuras estrechas, pliegues ...
    También se usa para aplicar
    la oclusión especular para evitar artefactos de iluminación brillante que aparece en mallas que son ocluida.

    Se calcula en mitad de la resolución original en una lectura de sombreado de píxeles desde el buffer de profundidad, mapas normales y especulares.
    El primer resultado obtenido es ruidoso.

    Reflexiones espacio en la pantalla

    Un pixel shader ahora genera la SSR mapa. It-ray rastros reflexiones utilizando sólo la información presente en la pantalla, haciendo rayos rebotan en cada píxel de la ventana, el color de los píxeles afectados por su lectura.


    SSR Mapa

    Las entradas del shader son el mapa de profundidad (para calcular la posición en el espacio mundial de píxeles), mapa normal (a saber cómo hacer que el rebote rayos), un mapa especular (para conocer la "cantidad" de la reflexión) y la trama anterior prestados ( en la etapa de pre-tonemapping pero posterior a la transparencia, a tener un poco de información de color). La configuración anterior marco cámara también se proporciona al sombreado de píxeles para que pueda realizar un seguimiento de los cambios de posición del fragmento.
    RSS es un bonito, no tan caro, la técnica de tener reflejos dinámicos en tiempo real que ocurren en la escena por un costo constante, lo que realmente ayuda a la sensación de inmersión y realismo.
    Pero viene con sus propios artefactos debido al hecho de que trabaja exclusivamente en espacio de pantalla y carece de información "global". Por lo que podría estar buscando a reflexiones agradables en una escena, pero a medida que comienzan a mirar hacia abajo, la cantidad de reflejo disminuye hasta que no hay reflexión en absoluto cuando se está buscando a sus pies. Creo que los relés de estado sólido en Doom bien integrados, que mejoran la calidad visual, pero son lo suficientemente sutil que no se notan desaparecer a menos que estés realmente centrarse en ellos.
    Estáticas cubemap Reflexiones

    Después de que todos los reflejos dinámicos de la pasada anterior (y sus limitaciones) ahora vienen las reflexiones estáticas usando IBL .
    La técnica se basa en 128 x 128 cubemaps pre-generados que representan el entorno de la iluminación de la información en diferentes lugares del mapa, que son llamados también "sondas medio ambiente". Exactamente igual que las luces y calcomanías que vimos previamente durante la clusterización de cono truncado, sondas también se indexan de la misma manera para cada grupo.
    Todos los cubemaps de nivel se almacenan dentro de una matriz, hay varias docenas de ellos, pero aquí están los 5 principales contribuyentes a esta escena (los cubemaps dentro de esta habitación):

    Un sombreado de píxeles lee de la profundidad, tampones, especulares normales, se ve arriba en la estructura de racimo que cubemaps influencia del píxel (cuanto más cerca del cubemap, más fuerte será su influencia) y genera un mapa de reflexión estática:

    Reflexión estática Mapa

    Mapas de mezcla Together

    En este paso de cálculo de un sombreado combina todos los mapas que fueron previamente generados.
    Se lee el mapa de profundidad y especular, y se mezcla la iluminación de la pase hacia adelante con:

    • la información SSAO
    • la RSS cuando este disponible para el píxel en cuestión
    • cuando la información de SSR no se encuentra, los datos del mapa de reflexión estática se utiliza como punto de retorno
    • algún efecto niebla también se computa


    Mezcla + Niebla: Antes



    Mezcla + Niebla: Después



    Mezcla + Niebla: Después




    AnteriorSiguiente

    • 1
    • 2
    • 3


    Iluminación de partículas

    Tenemos algunas partículas de humo en esta escena y la iluminación se presenta en realidad por el sprite.
    Cada uno de sprites se representa como si estuviera en el espacio mundo: desde su posición, algunos lista de luz y sus respectivos mapas de sombras se recuperan, y la iluminación en el quad se calcula. El resultado se almacena entonces en una baldosa de un atlas 4k, baldosas pueden ser de diferente resolución basada en la distancia de las partículas de la cámara, los ajustes de calidad ... El atlas ha dedicado regiones para los sprites de la misma resolución, aquí es una visión general de 64 x 64 sprites:

    Iluminación de partículas Atlas

    Y esto es sólo la iluminación de la información que se almacena a tan baja resolución. . Más tarde, cuando una partícula está dibujado, la resolución completa de la textura se usa y el patio de iluminación es mejorada y se mezcla con ella
    Aquí es donde DOOM desacopla el cálculo de iluminación de partículas procedentes de la prestación principal real del juego: independientemente de la resolución que ' volver a jugar en (720p, 1080p, 4k ...) iluminación de partícula es siempre calculada y almacenada en estas baldosas de tamaño fijo diminutos.
    Descendente de la escala y la falta de definición

    La escena se reduce proporcionalmente a varias veces, hasta 40 píxeles. Los niveles de reducción de escala más pequeños son borrosas mediante pases verticales y horizontales separados.

    ¿Por qué se realiza esta falta de definición tan temprano? Dicho proceso se realiza generalmente en el extremo durante el post-procesado para hacer un efecto floración de las áreas brillantes.
    Pero aquí todos estos diferentes niveles de desenfoque será muy útil en la siguiente pasada cuando la prestación de refracción de vidrio.
    Los objetos transparentes

    Todos los objetos transparentes (vasos, partículas) se representan en la parte superior de la escena:

    Antes de objetos transparentes:



    Los objetos transparentes: Abierto




    AnteriorSiguiente

    • 1
    • 2


    Vidrios hacen muy bien en Doom especialmente los vidrios esmerilados o sucias: las etiquetas se utilizan para afectar sólo una parte del vidrio para hacer su refracción más o menos borrosa.
    El sombreado de píxeles calcula la "borrosidad" factor de refracción y selecciona de la cadena de la falta de definición del 2 Los mapas más cercanos a este factor de borrosidad. Se lee a partir de estos mapas 2 y luego interpola linealmente entre los 2 valores para aproximar el color borroso final de la refracción se supone que tiene. Esto es gracias a este proceso que las gafas pueden producir buen refracción en diferentes niveles de borrones en un pixel-base por.
    distorsión Mapa


    distorsión Mapa


    Muy áreas calientes pueden crear distorsión por calor en la imagen. Aquí elNido Gore distorsiona ligeramente la imagen.
    Las distorsiones se vuelven contra el buffer de profundidad para crear un mapa de distorsión de baja resolución.
    Los canales rojo y verde representan la cantidad de distorsión a lo largo del eje horizontal y vertical. El canal azul contiene la cantidad de desenfoque de aplicar.
    El efecto real se aplica más tarde como un post-proceso usando el mapa de distorsión saber qué píxeles deben moverse alrededor.
    Aunque en esta escena en particular, que es sólo una sutil distorsión no es realmente notable.

    Interfaz de usuario


    IU


    La interfaz de usuario se representa a un render-objetivo diferente, en el modo alfa premultiplicado almacenada en LDR formato.
    La ventaja de tener toda la interfaz de usuario en un búfer separado, en lugar de dibujo directo en la parte superior del cuadro final, es que el juego podría aplicar algún filtro / post-procesamiento como la aberración de color o distorsión visual en todos los widgets de interfaz de usuario a la vez en una sola pasada.
    La prestación no utiliza ninguna técnica de procesamiento por lotes, en particular, recoge elementos de interfaz de usuario, uno por uno, en cerca de 120 llamadas de dibujo.
    En pasadas posteriores, la memoria intermedia de la interfaz de usuario se mezcla en la parte superior de la imagen del juego para producir el resultado final.

    Temporal anti-aliasing y el movimiento borroso

    TAA y el desenfoque de movimiento se aplican usando el mapa de velocidades y los resultados de representación de los fotogramas anteriores.
    Los fragmentos pueden ser retroprojected por lo que el sombreado de píxeles sabe dónde está el píxel se está procesando actualmente se encuentra en el cuadro anterior. La prestación en realidad se desplaza ligeramente mallas de proyección por medio pixel cada dos fotogramas: esto ayuda a eliminar los efectos de aliasing subpíxel.


    TAA y el desenfoque de movimiento: Antes



    TAA y el desenfoque de movimiento: Después




    AnteriorSiguiente

    • 1
    • 2


    El resultado es muy agradable: no sólo los bordes de malla se vuelven suaves, pero el aliasing especular (en un solo píxel brillante haría estallar en paz por un marco) también está a cargo de. La calidad es mucho mejor que lo que podría lograrse a través de un método de post-proceso como FXAA.
    escena de luminancia

    Este paso calcula el promedio de luminancia de la escena, que es uno de los parámetros alimentados a la tonemapper más tarde.
    El tampón de iluminación HDR se escala reducida a la mitad de su resolución en un bucle hasta que se convierte una textura 2 x 2, cada iteración calcula el valor de color de pixel como el promedio de la luminancia de sus padres 4 píxeles del mapa de mayor resolución.
    Florecer


    Florecer


    Un filtro de paso brillante se aplica a dim-abajo las zonas más oscuras de la escena.
    El resultado del filtro de paso brillante se escala reducida entonces en un bucle y borrosa en un proceso similar que vimos anteriormente.
    Las capas se difuminan con un desenfoque gaussiano separado en un pase vertical y horizontal en la que un pixel shader calcula una media ponderada a lo largo de una dirección.
    borrosas capas se combinan para crear la floración, que es una textura HDR en ¼th de la resolución original.

    Final de post-procesamiento

    Todo este paso se lleva a cabo en un solo pixel shader:

    • de distorsión por calor se aplica la lectura de los datos de mapa de distorsión
    • se añade la textura floración en la parte superior de la memoria intermedia de iluminación HDR
    • se realizan efectos como viñetas, la suciedad de la lente bengalas /
    • la luminancia media se recupera mediante el muestreo de la centro del mapa 2x2 luminancia y con los parámetros de exposición adicionales, se aplican los tonemapping y corrección de color.


    Tonemapping: Antes



    Tonemapping: Después




    AnteriorSiguiente

    • 1
    • 2


    El tonemapping toma el tampón de iluminación HDR que contiene colores que varían dentro de una amplia gama de luminosidad y la convierte a 8 bits por componente (LDR) por lo que el marco se puede visualizar en un monitor.
    Un
    operador tonemapping fílmico basado en el (x(Ax+BC)+DE) / (x(Ax+B)+DF) - (E/F)se utiliza la ecuación, es la tonemapper Uncharted 2 , también presente en GTA V .

    Tenga en cuenta que todo el tinte rojo general de la escena proviene de corrección de color.
    IU y Grano de película

    Por último, la interfaz de usuario se mezcla en la parte superior del bastidor de juego y al mismo tiempo una sutil película de grano se aplica.

    IU - Grano de película: Antes



    IU - Grano de película: Después




    AnteriorSiguiente

    • 1
    • 2


    ¡Uf! Hemos terminado con el marco que ahora se puede enviar al monitor de pantalla, que era un buen montón de cómputo, pero todo esto ocurrió en menos de 16 ms.
    DOOM logra producir una gran calidad visual a un alto rendimiento, ya que hábilmente re- utiliza los datos antiguos computados en los cuadros anteriores. En total fueron 1331 llamadas de drenaje, 132 texturas y 50 objetivos rinda utilizados.
    Notas de bonificación

    Primer plano sobre el vidrio

    La prestación de cristal es muy agradable y se consigue con medidas relativamente sencillas como hemos visto antes:

    • preparar varios niveles de la falta de definición de las mallas opacas representación
    • dibujar objetos translúcidos regreso a la delantera en modo de avance de colocarlas / iluminación / sonda de reflexión, utilizando la cadena anterior para diferentes valores de la falta de definición de refracción de vidrio, por lo que cada píxel puede tener es el propio valor de refracción.


    Vidrio: Antes



    Vidrio: Después




    AnteriorSiguiente

    • 1
    • 2


    Profundidad de campo

    El marco estudiado en la descomposición en realidad no muestran ninguna profundidad de campo por lo que vamos a considerar la siguiente escena antes y después de aplicar el DOF:

    DOF: Antes



    DOF: Después




    AnteriorSiguiente

    • 1
    • 2


    No todos los juegos funcionan correctamente DOF: el enfoque ingenuo es a menudo utilizar un desenfoque gaussiano y hacer todo el desenfoque en una sola pasada, según la profundidad del píxel. Este enfoque es simple y barato, pero tiene varios problemas:

    • mientras que la falta de definición gausian es bueno para la floración no es correcto para crear bokeh : en realidad se necesita un kernel plana para que la luz de un píxel brillante extendido por todas partes en un disco o una forma hexagonal ... Un Gauss no puede crear formas agradables bokeh.
    • DOF realizar en un solo disparo de un pixel shader puede conducir fácilmente a los artefactos de la coagulación.

    DOOM hace DOF correcta y el enfoque elegido es en mi experiencia entre los que da los mejores resultados:
    De campo lejano y de campo cercano se crean las imágenes: selección de píxeles se realiza en función de su profundidad y en parámetros DOF.

    • De campo cercano puede estar fuertemente borrosa, más se va a sangrar en píxeles detrás de él, mejor.
    • Campo lejano también es borrosa, pero no ha leído ninguna de píxel desde el / área de enfoque de campo cercano, por lo que evita cualquier problema con objetos en primer plano sangrado erróneamente a un segundo plano.


    Campo lejano



    Campo Lejano - la falta de definición # 1



    Campo Lejano - la falta de definición # 1 y # 2




    AnteriorSiguiente

    • 1
    • 2
    • 3



    Para crear los borrones bokeh, DOOM trabaja a media resolución y lleva a cabo un disco de toma estable con 64 grifos textura, cada muestra que tienen el mismo peso para el brillo realmente se propaga por todo a diferencia de un desenfoque gaussiano.
    El diámetro del disco puede variar en un pixel per concreto, en función del píxel
    CdC valor.

    A continuación, se extiende aún más el desenfoque con una falta de definición de 16 grifos, pero esta vez no calcula un promedio ponderado, simplemente se acumula los valores de la muestra y mantiene el valor más alto de la vecina grifos, así que esto no sólo ampliar la primera falta de definición que también corrige los pequeños artefactos (BPA) en el muestreo de la primera pasada. Esta última parte se inspira en la obra de McIntosh .
    Dicha técnica de la iteración sobre varias pasadas puede producir muy buenos grandes borrones mientras que aún permanecen en cuanto al rendimiento eficiente, el número de tomas textura reales realizadas por píxel es todavía bastante bajo teniendo en cuenta el amplio radio de la final disco-desenfoque obtenido.


    Lejos y de campo cercano imágenes son finalmente compuestas en la parte superior de la escena original con mezcla alfa para crear la profundidad final de efecto de campo. Este paso se realiza justo antes de aplicar el desenfoque de movimiento.
    más lectura

    Si quieres profundizar más en la tecnología idTech 6 hay, afortunadamente, una gran cantidad de discursos y materiales públicos disponibles:


    http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/

  12. #52
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Estuve analizando la Iluminación Global de crysis 3 y hice unas fotos de ON/OFF, lastimosamente el comando no me funciono y la única forma fue bajando los settings de bajo a muy alto (en bajo la GI se desactiva). Tambien no pude encontrar información de que GI usa el juego, lo mas que encontré fue lo de la tech demo "3 generacion de Iluminación global" pero no se si es con técnica de voxel o si usa su GI "Diffuse Global Illumination" que tampoco se si basa en Voxel, pero aqui esta la diferencias:



    Usa una cosa llamada cascade Light Propagation Volumens, y no es la GI basada en voxel de las demos que también puede hacer el motor... es su versión barata para que funcionase en la PS3, después de calcular la iluminación directa, se calcula la indirecta de modo aproximado mediante armonicos esféricos o SH o como se quiera llamar, un método bastante burdo en el que la radiosidad independientemente del angulo de la superficie, su forma o la incidencia de la luz sobre esta, se propaga desde la superficie iluminada como si fuera una esfera... tiñendo los objetos cercanos todos mas o menos de la misma manera, cuyo degradado depende mas de la distancia al centro de la esfera creada, que de lo que vendría siendo un rebote real.

    Es como si los objetos tuvieran una niebla esférica alrededor de ellos... que al iluminarse el objeto crea iluminación indirecta imprecisa y barata.

    La verdad que el rendimiento de tenerla activa o no es bastante nulo 6fps en alguna escena con demasiada luz inderecta:

    Porcierto en el juego hay un comando que se llama "e_GIIterations" que su valor es 10 , supongo que se referirá al numero y distancia de los objectos que "tiñe" no?, un numero mas alto debe tener un impacto en el rendimiento.

    PD: Bueno al parecer ningún comando de la GI funciona

    Directx 12 y Vulkan: next-gen APIs, compatibilidad, noticias, benchmarks, etc. - P

    -----------

    En principio the witcher 3 parece que tiene 4 cascadas, aunque la 4 no le noto que haga nada.



    Cascada 4 a 0


    Cascada 4&3 a 0


    Cascada 4&3&2 a 0




    Si parece que la zona 4... exceptuando casos muy concretos sobraba...

    El tema es que desde las primeras implementacion de mapas de sombras, esta simple iluminación que es una de tantas que se usan en la escena se ha vuelto de una complejidad asombrosa... por poner un ejemplo en bruto en cuento a efectos masivos en exteriores:

    Crysis mete shadow maps CSM (Culling shadow map), es bastante estática y tiene serio problemas para ajustar el angulo del sol con respecto a la sombra en si... sombras poco precisas o eso dicen, llega un tío lo mejora y lo llama PSSM (Paralelo split shadow maps), para poder ajustar mejor la variación angular, ni animación y con ciertos artefactos, luego llega otro le da otra vuelta y se saca de la manga VSM (Varince shadow maps), sombras mas suaves que ocultan el parpadeo que viene de perlas para mejorar el ciclo día noche (Assassins creed 2) y luego viene exponecial shadow maps ESM que hace lo mismo que lo otro pero mejor... mas preciso y mas rápido y terminamos optimizándolo con los mapas de sombras en cascada para ahorrar aún mas rendimiento... pero dentro de una misma escena solo en mapas de sombras nos podemos encontrar dependiendo del objeto deferentes técnicas con el fin de optimizar recursos, he incluso si el objeto es móvil nos encontraremos cosas de iluminación de interiores como cube shadow maps... vamos un locurón y mejor lo dejamos por que es un tema realmente complejo en el que los mismo expertos se vuelve locos pidiéndose consejos entre ellos cuando las cosas no les salen como quieren, y lo mejor es que ni siquiera encuentran una respuesta clara a los bugs... mas bien es un caso de prueba y error.
    http://foro.noticias3d.com/vbulletin...38117&page=654

    -----------

    Iniciado por Fear effectYa tiene parte precálculada y parte dinámica, pero al ser sobre objetos estáticos que no se mueven se puede precalcular casi todo y ofrecer el efecto de un modo tan masivo.. es u buen truco pero un truco al fin y al cabo, en lo que hay que calcular 3 cosas, angulo sobre el sol según donde este, inclinación/profundidad de esa sombra respecto al sol dependiendo de su altura, y tonalidad, que seguramente esta también sea precálculada con 10 o 12 rangos para atardeceres/amaneceres, lluvia, noche etc, pero esto a niveles de calculo es irrisorio auque haya 1000 mapas de sombras en la escena, una unidad de computo como es una tarjeta gráfica con proceso SIMD lo puede hacer en unos pocos ciclos.

    Pero si fuera iluminación directa dinamica real entonces la cosa se pondría peluda de narices, para objetos animados, NPCS (Algunos no todos muchos de ellos los apañan con mapas de sombras animados), se tiene que usar una técnica llamada shadow volumen, y esta si que requiere cálculos de shader geométricos... por que es en tiempo real, se trata de extrusionar la silueta del objeto en relación al foco que la ilumne y guardarla una especia de mapa de sombras almacenada en el stencill buffer... es bastante mas pesada que la otra, por eso no se utiliza de manera masiva y siempre que se pueda se utilizaran mapas de sombras precalculados.


    Si usara este tipo de iluminación directa real, no se verían los fallos que se ven, sombras que no están, sombras que desaparecen en parte, y sombras que no se mueven junto con el árbol, pero claro los frames serían pura pénita, de todos modos en objetos estáticos como los arboles con cierto cuidado y depuración y trabajo a nivel artístico sería casi imposible encontrar el truco, es mas en muchas ocasiones lo precálculado tiene mas calidad que lo real time... por que aqui para optimizar y ahorrar capacidad de proceso se tiende a simplificar los vértices de la silueta buscando un compromiso calidad/rendimeinto, mientras que los shadow maps solo depende del fillrte y de la memoria disponible.



    Ya que metiste la técnica de carmack usada en doom3 si no me equivoco, el shadow volumé y el shadow s mapping son considerados técnicas en real time, ya que los 2 hacen cálculos en real time.

    En el caso del shadows Map primero hace un cálculo en real time ( que este cálculo lo hará tu PC) y luego lo almacena, el gran detalle está que lo almacenado solo sirven para sombras estática , que no cambian de pocision y podés tirar de ese búfer:

    Como ejemplo: Si tengo un barril , shadows Map calcula en tiempo real la pocision,profundidad etc y luego almacena ,pero si ese barril es dinámico y tu lo mueves esa copia almecenada en el buffer no te vale, tiene que volver calcular la nueva posición del barril.

    Si es to lo aplicamos TW3 cada vez que el sol se mueve y esa sombra cambia de pocision , se tienen que volver a calcular todo. Esto en un entorno dinámico,mas que un sombras precalculadas, sería una escena recalculada xD, lo que viene derivando en cálculos en real time a lo bestia.

    Pero si lo que dices es posible de meter todo el ciclo en buffer teniendo en cuenta que no todo el escenario es lo mismo( hay objetos en posición diferentes) y lo luego almacenarlo todo, sacó esas conclusiones:

    - eso no se puede hacer.
    - consumirá mucha, mucha memoria.
    - Y si se pudiera hacer el juego tendría 2 etapas, la primera sería lo de ir calculando toda la posibles variantes el primer cliclo, en el segundo ciclo el rendimiento del juego subiría como espuma ya que todo estaría precalculado y no tendría que volver a calcular. Y con más de 300 horas de juego eso nunca pasó.

    Pero es que con solo leerme es 99℅ imposible, con pequeñas variaciones en la sombras se tendría que volver a recalcular esa sombra. El precalculado solo vale para objetos estáticos es la ley del renderizado, en antaños se usaban muchas técnicas precalculada s porque no se podía mover ni un vaso.

    Y vuelvo a repetir el shadow map es un sombreado en real time es su primera etapa calcular y eso lo hace tu PC por el cual, el rendimiento se ve afectado y lo segunda etapa es que lo almacena ,pero lo que almacena sólo vale para objetos estáticos que se encuentra en la misma posición.

    En mi opinión ( está si es mi opinión) en juegos como TW3,stalker,gta V, farcry 3 por su dinamismo el shadow s Map lo que hace es recalcular(lo que viene siendo calcular en real time) a saco y esto se puede apreciar en el impacto del rendimiento que se tiene de pasar de iluminación estática a una Iluminación dinamica completa y como digo si fueran precalculada s en segundo ciclo día y noche, el rendimiento subiera notablemente porque estaría precalculadas y guardas en el búfer, tu equipo no tendría que volver a calcular.

    Saludos.

    http://foro.noticias3d.com/vbulletin...38117&page=653
    Última edición por Activity; 02/10/2016 a las 03:13

  13. #53
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia


  14. #54
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Y ese pegote van cambiando de posicion durante el transcurso del dia, conforme la luz directa del sol se va moviendo o cuando hay tormenta y el sol se tapa esas sombras desaparecen, vamos todo precalculado..........................XD. En serio es imposible de pre calcular algo asi, y hora resulta que la Iluminación Dinámica completa no existe y todo es precalculado. Dejo esta información de las iluminación que hace uso stalker:

    Iluminación Estática

    Este modo de iluminación es dado por el uso del DirectX8, con todas sus facultades y desventajas. Este método de iluminación proporciona sombras básicas que solo se proyectan tomando en cuenta la posición de algunas de las fuentes de luz (Ej, Hogueras, faroles, linternas, etc). Este método produce sombras de baja calidad y bastante simples. La ventaja de todo esto es que posee mucha menos carga gráfica en la placa de vídeo, por lo tanto, se debería notar un buen rendimiento con respecto a los modos de iluminación dinámica, ya que esta es mucho más compleja. Recomendado para placas de vídeo antiguas, sin mucha memoria (Ej, Series 6 de GeForce) o si simplemente el juego no funciona lo demasiado fluido para jugar en los modos de iluminación dinámica.

    Iluminación Dinámica de Objetos

    En este modo, se utiliza el DirectX9 esto proporciona fuentes de luz detalladas y habilita (sin posibilidad de deshabilitarlo) el HDR (o High Dinamic Range lighting). La cantidad de recursos necesarios para la calidad gráfica mostrada aumenta considerablemente en este modo, por lo tanto placas un poco antiguas probablemente no puedan mover este modo de iluminación fluidamente. Esta vez la mayoría de los objetos proporcionan sombras dinámicas (Ej, edificios, autos, etc), lo que significa que cambian constantemente según donde y en qué ángulo se ubique la fuente de luz con respecto al objeto. De nuevo, este modo consume muchos recursos de la PC así que sería recomendable para sistemas actualizados pero no demasiado potentes. Este modo proporciona buena calidad visual y no produce tanto impacto en el rendimiento como el modo de iluminación dinámica completa.

    Iluminación Dinámica Completa

    En este modo todas las fuentes de luz son tomadas en cuenta (se agregan fuentes como el sol y las ya existentes actúan sobre todo los que las rodea) y todo los alrededores producen sombras dinámicas. Este modo es especialmente “pesado” para la mayoría de las PCs, ya que requiere no solo gran capacidad de procesamiento por parte de las placas de vídeo sino también grandes cantidades de memoria RAM para poder soportar la gran cantidad de cálculos que se necesitan para proyectar las sombras adecuadamente. Por supuesto, la calidad gráfica en este modo es muy alta y los paisajes e interiores se verán muy bien en este modo, pero solo es recomendado para las PCs actualizadas con gran cantidad de recursos, ya sea memoria de vídeo, como memoria RAM del sistema y un buen procesador.



    Como se observa en el minuto 2:16 cuando la nube tapa el sol, las sombras desaparecen (como debería ser), lo precaculado solo vale para objectos estaticos , para un entorno tan dinamico, es imposible ponerte a predecir las mil variantes que puede tener cada objectos, un ejemplo seria si encontras un barril, y ese barril lo desplazas por todo el escenario y va generando sombra de acuerdo a la pocision de la luz directas y la posicion del barril, para hacerlo pre calculado tendrías que predecir todos los movimientos, y en un escenario tan grande tendrás miles si no millones de movimientos que podras hacer, vamos es prácticamente imposible, si o si tiene que ser en real time, sumandole los movimientos del sol, el clima etc.
    Iniciado por stalker77XD es pero que me estés trolleando.

    Como va ser posible pre-calcular una escena semejante donde dependiendo de la pocision del sol esas sombras dinámicas van cambiando de pocision conforme va trascurriendo el día, GIF jeje? eso no es ningún gif, las escenas precalculadas solo sirven para objectos estaticos , porque para precalcular algo tenes que anticipar el movimiento la trayectoria, eso en un entorno como The Witcher 3 es 100% imposible calcular de manera anticipada las miles de varientes que puede tener una sombra, no se van a poner a precalcular la sombras de cada árbol y la poción diferente de ese arbol por cada segundo donde el sol va cambiando de pocion, o los objectos que no son parte de la escena, no terminarían el juego nunca XD.



    Por partes... no ves que no tiene ningún sentido poner en un mismo párrafo que es imposible ir cambiando la posición de los mapas de sombras mientras va trascurriendo el día, ¿y luego decir que para hacerlo tienes que anticipar el movimiento trayectoria?, te voy a contar un secreto pero no se lo digas a nadie, el sol en el brujo sale siempre por el mismo lado y se va por el mismo lado siguiendo una trayectoria, y me han dicho las malas lenguas que puede que la luna por envidia este haciendo lo mismo.

    No... hablando en serio.... por que veo que no has entendido absolutamente nada de lo que quise decir, la iluminación en este juego como en todos desde 1993 se hace por medio de mapa de sombras precálculados, como se apliquen ya es otra historia, como veo que te cuesta entender esto te voy a explicar como se hace un mapa de sombras, por que los motores nuevos son muy chulos y lo hacen todo de manera bastante automática sin tener que entrar en profundidad en tema de iluminación.


    Ves las pelotitas... pos imagínate que son arboles, ahora cuando ya tienes el objeto 3d del que quieras proyectar una sombra miras su contorno y guardas algo parecido a esto.



    Y luego con esta textura, dependiendo de donde este colocado el sol en ese momento la proyectas sobre el escenario, con su angulo y dirección que desees... que una vez guardado este mapa ya puede hacer con el lo que te de la gana, le puedes cambiar la tonalidad, los degradados grises, lo que te plazca.



    Esta claro que no vas a poner un mapa de sombra con tantos objetos, contra mas pequeños mas flexible y propicio es para mostrar ciertos trucos que hagan la iluminación mas creíbble.

    Como ejemplo te diré que los propios arboles en si ya llevan varios mapas de sombras para las ramas, y con un simple adaptación del angulo de rotación ya se consigue que la sombras e mueva como si le golpeara el viento

    Iniciado por stalker77
    Y la razón porque en TW3 el pasto no genera sombra es porque lo an desactivado, en Stalker las sombras solares en la hierba se puede desactivar para ahorrar rendimiento, solo hay que ver como en el video que puse es Titanx va con lo justo, son demasidos sombras y cálculos en Real-time.

    Y yo no veo que en TW3 se generen sombras que no sean parte de cada arbol, todas las sombras que e analizado pertenecen a cada arbol, que este mas definidas o no, eso dependera de la resolucion de las mismas TW3 utliza una resolucion de 3072 en ultra, otro video mio, no hay sombra precalculadas en un entorno asi, seria un trabajo infinito:





    No han hecho mapas de sombras para el pasto por que eso hubiera multiplicado el numero de mapas de sombras por 3, consumiendo mucha mas memoria, no la han desactivado, es una decisión de diseño, ademas tendrían que haber hecho mapas de sombras en plan gift que es lo que no te llegaba a entrar en la cabeza.... luego hablare de esto.

    Lo curioso es que me dices en el tamaño que han guardado los mapas de sombras, y me dices que no hay nada guardado ni precálculado...



    Ahora me cuelgas ese vídeo, y dice que todas las sombras salen de cada arbol sin fallos iluminación directa tiempo real everywere, y en la mitad del camino hay una sombra en dirección contraria al sol de un arbol sin hojas que no consigo ver de donde sale... es un bug... si si la del segundo 14... la que no se mueve.

    De todas formas los compañeros ya te han puesto ejemplo de cosas que no están bien, y sería imposible que ocurriesen si fuera un algoritmo de iluminación global que proyectara sombras calculándolas directamente sobre las siluetas de los objetos... pero este ultimo del compañero a sido muy interesante para explicar como es un mapa de sombras animado.
    https://www.youtube.com/watch?v=e2J7Bz6DcJY

    El palo es un mapa de sombras muy sencillo un réctangulo... y aparte para la bandera se ha hecho una especie de gift para proyectar esa sombra que se mueve, pero son mapas de sombras independiente, similar a los comentado antes sobre las ramas de los arboles.

    PD: Sobre el publipost de stalker de para ponerlo al máximo necesitas un pepino de cuidado por que necesitas mucha memoria ram para procesar datos... mejor no comento nada... necesitas mucha ram y vram para almacenar muchos mapas de sombras previamente calculados, y necesitas mucho fillrate para dibujarlos echando ostias.
    El shadows map no es una técnica 100% precalculada, esto solo sirve para objetos estáticos donde previamente guarda la información y la almecena para reutilizar,como lo sería la técnica de tiling te de texturas.

    En un entorno dinámico con ciclo de tiempo el shadows Map tiene que estar actualizando esos buffer constantemente para volver a calcular las pocision de los objetos, al final de cuentas como comprenderá s el shadow map calcula en tiempo real la pocision del objeto antes de almacenarla,pero para reutilizarla y ahorrarte tiempo de cálculo de dibujo, la escena se tiene que repetir y eso en un juego dinámico, donde lapso de tiempo, ciclo de tiempos meteorologicos, es muy improbable, por cual tiene que estar actualizando y calculando constamente. Con esta técnica te podrás ahorrar mucha potencia en juegos totalmente estáticos.

    Pero al final es un técnica en real time, esos cálculos que luego almacena los hace tu PC.

    Directx 12 y Vulkan: next-gen APIs, compatibilidad, noticias, benchmarks, etc. - P

    ---------

    Cita Iniciado por Fear Effect
    Ya pero es que ese tipo de iluminación es de la generación de la ps3 (GOW3 por ejemplro), los motores modernos hace un lustro que con mejor o mayor acierto usan algún tipo GI real time, aun que sea solo para salas y objetos grandes... paredes mayormente, tanto UE4, Cryengine 3, Frostbite 2, Fox engine, Luminus etc, usan GI de mayor o menor calidad... eso de sombras precálculadas, ademas de cantar un montón en ciertos momentos no es digno de un juego gráficamente puntero.



    Pero de todas formas es que ellos te están explicando que lleva:

    Global illumination, which is baked offline, uses hundreds of thousands of lighting probes... ilumnación parecida al the order 1886, todo prerender, eso en este juego queda bien, en un juego que puede mover focos objetos, luces... no, y encima la iluminación directa sobre npcs falla... el propio protagonista no proyecta sombra...
    http://foro.noticias3d.com/vbulletin...38117&page=650
    Última edición por Activity; 02/10/2016 a las 03:21

  15. #55
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Cryengine directx 12 y Vulkan con nuevas formas de renderizar



    Unreal Engine 4 | Reflections Subway Demo | GTX 780 Ti



    Hay muchos videos de motores y efectos..

    Top 5 Best Next Gen Game Engines Of The Future


    Unity Engine Demo - Full Real Time Rendered "Adam" Short Film (Realistic Graphics)



    Pero todo esto ya entra dentro de los motores...y directx 12 o 12.1,etc

    Nuevo Unreal Engine y motores nuevos

    http://www.chw.net/foro/tarjetas-vid...x-12-a-19.html
    Última edición por Activity; 02/10/2016 a las 03:31

  16. #56
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    GameWorks VisualFX Overview

    NVIDIA VisualFX provides solutions for complex, cinematic visual effects. The libraries are robust, easy to integrate and provide multi-platform support. A lot of the NVIDIA VisualFX libraries have been already used in games. If you are interested in licensing any of our technologies for your game, please contact us.
    NVIDIA Volumetric Lighting
    [COLOR=rgba(255, 255, 255, 0)]Cinematic Smoke and fire ...



    Atmospheric light scattering.


    NVIDIA FaceWorks
    [COLOR=rgba(255, 255, 255, 0)]Advanced skin rendering ...[/COLOR]

    Advanced skin rendering


    NVIDIA HairWorks
    [COLOR=rgba(255, 255, 255, 0)]Dynamic hair and fur ...[/COLOR]
    Dynamic hair and fur


    NVIDIA FleX
    [COLOR=rgba(255, 255, 255, 0)]Unified GPU simulation pipeline[/COLOR]
    Unified GPU simulation pipeline


    [/COLOR]
    NVIDIA Turf Effects
    [COLOR=rgba(255, 255, 255, 0)]Realistic grass simulation


    Realistic grass simulation

    NVIDIA WaveWorks
    [COLOR=rgba(255, 255, 255, 0)]Natural ocean simulation ...[/COLOR]
    Natural ocean simulation


    NVIDIA VXGI
    [COLOR=rgba(255, 255, 255, 0)]Global Illumination ...[/COLOR]
    Global Illumination


    NVIDIA Turbulence
    [COLOR=rgba(255, 255, 255, 0)]High fidelity particle simulation ...[/COLOR]
    High fidelity particle simulation


    [/COLOR]
    NVIDIA ShadowWorks
    [COLOR=rgba(255, 255, 255, 0)]HBAO+ and adv. soft shadows ...


    HBAO+ and adv. soft shadows

    NVIDIA PostWorks
    [COLOR=rgba(255, 255, 255, 0)]TXAA and DoF (Bokeh) ...[/COLOR]
    TXAA and DoF (Bokeh)


    NVIDIA-VXAO
    [COLOR=rgba(255, 255, 255, 0)]High quality ambient occlusion ...[/COLOR]
    High quality ambient occlusion


    NVIDIA FlameWorks
    [COLOR=rgba(255, 255, 255, 0)]Fire, smoke and explosion effects for games ...[/COLOR]
    Fire, smoke and explosion effects for games


    [/COLOR]
    NVIDIA Flow
    [COLOR=rgba(255, 255, 255, 0)]Combustible fluid, fire and smoke simulation ...


    Combustible fluid, fire and smoke simulation

    NVIDIA HFTS
    [COLOR=rgba(255, 255, 255, 0)]Hybrid Frustum Traced Shadows ...[/COLOR]
    Hybrid Frustum Traced Shadows



    [/COLOR]

    NVIDIA GameWorks Videos

    [COLOR=rgba(255, 255, 255, 0)]Watch Video [COLOR=rgba(118, 185, 0, 0)][/COLOR][/COLOR]

    NVIDIA HairWorksDynamic hair and fur simulation ...



    [COLOR=rgba(255, 255, 255, 0)]Watch Video [COLOR=rgba(118, 185, 0, 0)][/COLOR][/COLOR]

    NVIDIA FlameWorksCinematic smoke and fire ...



    [COLOR=rgba(255, 255, 255, 0)]Watch Video [COLOR=rgba(118, 185, 0, 0)][/COLOR][/COLOR]

    NVIDIA FaceWorksAdvanced skin shading ...



    Watch Video

    NVIDIA WaveWorksNatural ocean simulation ...




    https://developer.nvidia.com/gamewor...ualfx-overview

  17. #57
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia


  18. #58
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia


  19. #59
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia

    Shadow Warrior 2 está bien optimizado, incluye nueva tecnología de NVIDIA

    Shadow Warrior 2 ha llegado al mercado con una optimización envidiable, ya que puede correr en un Core i3 de cuarta generación o superior y una GTX 750 TI en 1080p y ajustes casi máximos sin problema.
    El juego soporta además la tecnología Multi-Res Shading de NVIDIA, que consigue mejorar considerablemente el rendimiento global.
    Dicha tecnología reduce la resolución en la zona más externa de la pantalla (los bordes) hasta el 60%, manteniendo la parte central en un 100%.
    Con esto se consigue incrementar el rendimiento sin que el jugador note una gran pérdida de calidad visual.

    Noticias3D - Shadow Warrior 2 est











    Última edición por Activity; 19/10/2016 a las 06:46

  20. #60
    Desterrado
    Fecha de ingreso
    05 Jan, 10
    Mensajes
    11,437

    Re: HDAO y SSAO,filtros MSAA amd, fxaa Nvidia


Página 3 de 4 PrimerPrimer 1234 ÚltimoÚltimo

LinkBacks (?)


Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •  
*