Source: http://disruptiveludens.com/nintendo-switch-y-resolucion-de-pantalla-feedback
Timestamp: 2020-08-05 04:04:18+00:00

Document:
Nintendo Switch y Resolución de Pantalla (Feedback) – Disruptive Ludens
Conceptos Básicos, Feedback, GeForce, Nintendo, Switch
Nintendo Switch y Resolución de Pantalla (Feedback)
Publicado por Urian en junio 1, 2020
¿Equivalente al DLSS en PS5? No más bien no.
Bill Trinen debería ser despedido.
Lo has enfocado desde el punto de vista equivocado:
Switch es más potente que Wii U, y Zelda BOTW va a 720 en modo portátil siendo un port de wii u.
Esto es una señora chapuza y ya está.
A ver, yo no he dicho en ningún momento que Wii U sea más potente que Nintendo Switch, lo que he dicho es que Switch tiene problemas de rendimiento cuando hay transparencias en la escena por déficit en el ancho de banda respecto a la tasa de relleno.
El problema de las transparencias es que la GPU ha de hacer los siguientes pasos
Escribir el color transparentado en el búfer de imagen, para transparentarlo se multiplica el valor de A por cada uno de los valores RGB.
Escribir el color de fondo y por tanto no transparentado.
Esto son varias escrituras a la RAM para un solo pixel, por lo que reduce la tasa de relleno. En cambio si tienes una memoria interna suficientemente rápida donde realizar dicha operación eso no ocurre como es el caso de los Tile Renderers y los sistemas con memoria embebida. ¿Cierto? Bueno, el problema viene con el Occlusion Culling o Z-Cull respecto a los Tile Renderers que no es otra cosa que la eliminación de pixeles de fragmentos durante la rasterización que son opacados por un objeto más cercano a la cámara en la misma posición (X e Y)
¿Como lo hace? Primero necesita tener ordenado cada fragmento según su posición en pantalla de tal manera (X e Y), luego coge un grupo de fragmentos con la misma posición de pantalla y los ordena según su valor en el Z-Buffering y escoge solamente el más cercano, eliminando al resto en la misma posición que no serían visibles y sería una tontería no renderizarlos.
¿Suena ideal no? El primer problema es que esto lo hace durante la fase de rasterizado donde desconocemos el color de los triángulos convertidos en fragmentos y por tanto el valor Alpha que es utilizado para las transparencias por lo que corremos el riesgo de eliminar un fragmento que luego sería visible debido a que el elemento que hay delante es transparente.
¿Pero acaso no es mejor enviar los triángulos de manera ordenada? Si, es cierto, pero el problema que tenemos es la ejecución Round-Robin de las GPUs, la idea de este método de planificación de las instrucciones es que cada una de ellas tiene un tiempo para ejecutarse, si no se soluciona en ese tiempo es retirada al final de la cola y se pasa a la siguiente hasta que tenemos los datos para solucionarla. Debido a que no todos los triangulos de la escena son iguales esto provoca que la geometría llegue desordenada a la unidad de rasterizado. La mejor solución es re-ordenar la geometría pero historicamente no todas las GPUs lo han hecho.
El caso es que nos podemos encontrar con fragmentos que coincidan en las coordenadas X e Y, pero cuyo Z es distinto. Una GPU que no ordene la geometría lo que hará será recibir los poligonos, los rasterizará y luego hará una comparación en el Z-Buffer de la imagen:
Si no había fragmento en esa parte de la pantalla entonces reescribirá el búfer de imagen con información del fragmento.
Si algunos pixeles del fragmento tienen un valor en el Z-Buffer > lo que hay en el búfer de imagen, esos pixeles son descartados.
Si algunos pixeles del fragmento tienen un valor en el Z-Buffer < lo que hay en el búfer de imagen, los nuevos pixeles reemplazan a los anteriores.
A esto se le llama Z-Cull u Occlusion Culling y el problema viene en que nos podemos encontrar que una GPU rasterice y dibuje en el bufer de imagen algo que no es visible o va a ser tapado por otro pixel. Por lo que lo mejor es tener un mecanismo que ordene la geometría de la escena previamente según su posición en pantalla y que dicho mecanismo sea capaz de antemano de descartar toda la geometría no visible en el fotograma. Pero esto conlleva consigo un problema y es que hemos de tener en cuenta que en el pipeline no conocemos el valor de color y trasparencia hasta después del rasterizado.
Por lo que sabemos que poligonos están por delante y cuales están por detrás en la imagen, pero no sabemos cuales son transparentes y cuales no. Una simple solución es poder marcar de antemano los polígonos transparentes con un bit especial de tal manera que a la hora de ser ordenados no sean descartados. En todo caso, las specs oficiales en el caso del Tegra X1 nos dan algunas pistas sobre su capacidad de hacer Z-Cull u Occlusion Culling.
Teniendo en cuenta que la unidad de rasterizado genera hasta 16 pixeles por fragmento, unos 256 pixeles significa que la GPU puede soportar un overdraw de 16 y por tanto gestionar una lista de hasta 16 triangulos por tile, la cual puede ordenar y descartar los no-visibles. Pero no sabemos si tiene la capacidad para manejar polígonos con transparencias, los cuales deberían estar marcados de antemano.
Para evitar esos problemas, en escenas en las que hay elementos con transparencia se desactiva el Z-Cull u Occlusion Culling durante la etapa de rasterizado, especialmente cuando hay objetos con transparencias en la escena. Esto aumenta la cantidad de elementos no-visibles que son texturizados y afecta negativamente al rendimiento.
Pero el problema con Switch son todos los efectos de post-procesado y que por tanto se hacen tomando del búfer de imagen. En esto es inferior a cualquier consola de la anterior generación…
Xbox 360 disponía de 10MB de memoria embebida donde realizar algunos efectos de post-procesado aprovechando el alto ancho de banda que otorgaba dicha memoria.
En PS3 no había memoria embebida, pero se enviaban los fragmentos ya texturizados a los SPE para que desde su memoria local hicieran post-procesado.
Wii U disponía de 32MB de eDRAM,
Hay una serie de efectos gráficos que dependen del ancho de banda del búfer de imagen y si esta esta recortado entonces la tasa de relleno baja, si la tasa de relleno baja entonces se dibujan menos pixeles en pantalla y hay menos resolución o menos tasa de fotogramas, pero es que el caso con la GPU de Switch no es exactamente ese ya que hay otro factor que limita la resolucion y tiene que ver con el Tile Caching.
A mi el juego me encantó (salvo el sistema de combate que era demasiado automático.).
Lo jugué en N3DS y los gráficos parecían imposibles para dicha máquina (se que la versión de Wii era mejor, pero no podía jugarse de forma portátil).
Se que esta conversion/remake ha estado limitada por el presupuesto (dicho por el propio director), y que han usado el Engine de Xeno2 (supongo que la versión más optimizada, la del dcl Torna).
Mi duda es respecto a las limitaciones de la máquina, más que nada por que esta gente fue la encargada de ayudar a Nintendo con Zelda Breath, haciendo un magnífico trabajo tanto en wii u (en la cual ya habían mostrado su maestría con Xenoblade Chronicles X), como en Switch, siendo un port de este.
A lo que voy: teniendo en cuenta las limitaciones de la máquina, ¿crees que se les ha «atragantado» la máquina? ¿Es cosa de los límites de presupuestos/tiempo, en xeno2 no hay duda, y en este no se si el tiempo ha perjudicado, pero el motor ya lo deberían tener optimizado?
Pregunto esto por el próximo Zelda, como tu has dicho no es un juego diseñado para Switch nativa mente, si no un port de la versión Wii u, y que había mucho margen de mejora.(Como en el resto de juegos de la primera hornada de Switch, siendo los de Nintendo juegos diseñados con Wii u en mente)
Supongo que esta gente les estará ayudando, ahora la duda :¿crees que habrá una diferencia significativa respecto al anterior Zelda?
Gracias y espero que te mejores pronto
(Por mi parte, al contrario que a ti, lo que me gustaría es que hubiera mazmorras, mezclando lo mejor de ambos tipo de Zelda, y si añadirán control por movimientos (aunque fuera opcional), al estilo Zelda SS, buff, podría convertirse en el mejor zelda/más divertido)
Más bien es el hecho de pedir peras al olmo y luego salir a quejarse.
El Tegra X1 simple y llanamente dibuja la escena tile por tile, el problema es que el tamaño de cada Tile es variable según la carga computacional que tiene este y la cantidad de información a procesar, por eso mencione la patente de la propia Nvidia sobre el Tile Caching y deje el video de hace unos años de David Kanter donde explica como rasterizan las Nvidia desde Maxwell.
El caso es que tenemos que entender como funciona la resolución dinámica y esta funciona teniendo una carga computacional fija en cada fotograma, obviamente si si esta aumenta entonces la solución más simple es variar la resolución hacía abajo y eso es lo que hacen las GPUs independientemente de la máquina. pero en los juegos de Switch pero con los Tiles, pero no aumenta ni disminuye el número de Tiles, solo los pixeles por tile afectando a la resolución final de salida.
No creo que sea un problema de los programadores, luego sumadle el hecho de que mientras las GPU Maxwell de escritorio tienen un ratio 512KB de Cache L2 por GPC, el X1 de Switch tiene un ratio de 256KB por GPC por lo que los Tiles van a ser la mitad de pequeños ya de base por el hecho de que disponemos de la mitad de la Cache L2 para almacenar el tile, el cual cambia su tamaño dinámicamente aunque siempre es de 4×4 bloques pero la cantidad de pixeles por bloque es variable.
No creo que sea tan dificil de entender la explicación, la cantidad de Tiles 410 en pantalla es fija, lo que no es fijo es el tamaño de cada tile que va fluctuando de un fotograma a otro.
Buenos días. ¿Qué opinas del AMD Ryzen C7 con núcleos ARM y GPU Radeon? ¿Está AMD intentando posicionarse para la carrera hacia la Switch2?
Tenia un borrador a medio hacer hablando del SoC y por falta de tiempo me lo filtran…
No te preocupes, creo que nadie ha profundizado en esa línea y creo que pocos podrán llegar a conclusiones a tu nivel.
Te pierdes en los detalles. Hay otros sandbox con transparencias que no tienen el pésimo rendimiento de esta chapuza.
Hola disculpa si es una tontera pero usar el cartucho para poner RAM otro poso y así aumentas el bus
Hola, parece que me expliqué mal (aunque se agradece mucho la explicación).
Mi pregunta básicamente era si te parece que a los desarrolladores de Xenoblade Chronicles se les ha atascado el hardware (ya que hay ejemplos muy superiores en Switch), o simplemente ha sido por falta de tiempo /dinero.
Lo preguntaba por lo que te comentaba : como han sido la compañía en ayudar a Nintendo con el Zelda, si se les ha atragantado quizá Nintendo busque ayuda en otra parte, solo eso.

References: Resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución