Polyteres escribió:Buenas gente, pero creo q tu sabes q hay cosillas q has obviado un poquito o bien has maquillado. Aunq en el ZPrepass y en los pases de sombra no estés usando ningun tipo de acceso a textura, si estás usando ancho de banda pq estás escribiendo en un buffer (y este será de 24 o 32 bits o sea igual q un render target RGB8/RGBA8). Por lo q eso de q no se usa ancho de banda en esos dos pases...se usa, en menor cantidad pero se usa. Si por ejemplo tienes un Cascade Shadow Map de 4 cascadas cada una de 1024x1024 a 32bits de profundidad ya estás usando un pellizquito... si estás haciendo la sombra de una luz omnidireccional y estás usando cube mapping ya tienes 6 texturas del tamaño q sea, y si usas Dual Paraboloid tienes 2...no se puede obviar tan a la ligera el ancho de banda q se usa en estos pases.
Bueno, tampoco creo que sea el hilo para concretar tanto pero bueno. Creo que no hay que confundir la finalidad del ancho del banda con la necesidad de allocatar recursos gráficos como pueden ser texturas. Evidentemente en estos procesos allocatamos texturas sea para el zPass o para las sombras, pero aquí lo que nos interesa no es el ancho de banda sino la velocidad de acceso a esa memoria.
Generar un buffer de zPass o crear las texturas de las sombras requiere generar las texturas y mantenerlas en memoria como RenderTargets. Más allá de esto, el ancho de banda necesario no viene por las texturas sino por el ancho de banda que necesite la geometría a renderizar sobre esas texturas, dado que estos dos procesos en concreto se basan en geometría no en texturizado. El ancho de banda necesario para geometría no es ni por asomo comparable a lo que se necesitaría para mover las texturas que en esta generación se moverán.
Por lo que, el generar los RenderTargets en eSRAM y según vayas sacando texturas de sombras ir pasándolas a la DDR3, aunque éste último proceso pueda penalizar, también es cierto que has ganado en cuanto al procesamiento dado que el acceso a eSRAM y a modificar estas texturas ha sido mucho más rápido.
Cierto es que en el deferred requerirás de esas texturas de las sombras en el DDR3 para componer la imagen final. Pero, de verdad no tenermos duficiente con cerca de 1.13 GB TEÓRICOS (para una tasa de 60fps) que nos ofrecería DDR3 de ancho de banda para acceder a esas texturas? O quizá incluso la menor latencia de la DDR3 me permitiría reclamar esas texturas de una manera más rápida?
Por otra parte como bien sabes, cuando se accede a una textura no solo se hace un único acceso, dependiendo del filtrado tendrás mas o menos accesos. Componer la imagen final de un deferred tb se come mucho ancho de banda, si tienes algún tipo de HDR real (nada de nao32 ni compresiones raras q ya estamos en la next gen y podemos pasar de esas cosas para conseguir mas calidad), todo el postprocesado q haces...todo se come ancho de banda.
Efectivamente, y como digo lo que importa en el número de accesos es la velocidad a la que puedes acceder a recursos y no la cantidad máxima de recursos a acceder que sería el ancho de banda.
Vuelvo a decir, un deferred no come ancho de banda. Un deferred REQUIERE de allocatar grandes recursos como pueden ser, en el caso que citaba, 3 texturas FullHD. Más allá de esto, tenemos el cuello de botella con el ancho de banda al hacer la primera pasada del deferred, dado que requerimos de TODAS las texturas en DDR3 que para generar ese frame necesitásemos. Una vez generado el G-Buffer no requiero de ancho de banda, requiero de acceso rápido sobre esa memoria y de la potencia de la GPU para hacer el cómputo final de iluminación. Sí es cierto que necesito dónde poner ese resultado, bien, tengo espacio para un cuarto RenderTarget, y de no tener espacio en la eSRAM, puedo colocarlo en la DDR3: más lento sí, pero lo que gano accediendo a toda velocidad a la eSRAM para hacer esos cálculos me lo compensa.
Una vez tienes el resultado albedo con iluminación final del deferred, puedes reutilizar alguna de las mismas texturas del deferred para los menesteres que comentas. De manera que todo el post-procesado (que es lo que más tiempo requiere) puede realizarse también en la eSRAM volviendo a ser el acceso muy rápido. A tener en cuenta que las técnicas de post-procesado requieren de una única textura origen y una de destino, ya que esto es screen-space. SSAO o por ejemplo hacer un blur requieren de RTs más pequeños pero como comento, hay que saber dónde poner cada cosa.
Pero no solo tenemos los 3 render target... tenemos los tres distribuidos como se dice mas uno para la acumulación de la iluminación, mas el back buffer final dnd se compone todo, mas todo lo q añade el MSAA, mas todos los buffer intermedios q se usarán en el postprocesado (el SSAO no se hace a la resolución completa por ejemplo) toda la composición del HDR (q esto si q se come y bien el ancho de banda), mas toda la resolución de la iluminación... Todo eso no coge en la eSRAM.
El deferred es una técnica devoradora de ancho de banda lo q se necesita precisamente es eso, no la baja latencia. La latencia en gráficos importa poco. El deferred para ir a lanzado necesita ancho de banda
El back buffer no lo necesitas hasta en el momento final en el que tienes el resultado del deferred y simplemente haces el blit encima, por lo que puedes tenerlo en DDR3 perfectamente.
Evidetemente seria genial tener 8GB de eSRAM pero me temo que eso es imposible. Pero tener aunque sean 32 megas de una memoria tan rápida en acceso y pensando perfectamente cómo optimizar un engine gráfico puede resultar una ventaja y no un inconveniente.
También veo como ejemplo Killzone, en el que usan un G-Buffer compuesto de 5 MRTs a 64 bits... es decir, ya esto mismo no te cabe en la eSRAM. Pero la pregunta es... saben lo que hacen? O es que simplemente al tener gigas de memoria a su disposición ni siquiera se preocupan lo más mínimo en optimizar las cosas un mínimo? Porque puedo comprender usar un mayor número de MRTs (quizá 4, 5 ya no sé para qué), pero es que encima de 64 bits es un despropósito. Por lo que, el espacio de la eSRAM puede ser pequeño pero bien usado algo muy interesante.
![[alien]](/images/smilies/nuevos2/alien.gif "alien")
![[flipa]](/images/smilies/nuevos2/flipando.gif "flipando")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
pero espero se me entienda.
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
