Comentario Original:
Me preguntaba si una cosa es el atlas y otra la cache para la página cargada del atlas, de tal modo que en un sandbox el atlas cubriria el mundo y cada pixel indicaria la página que se usa para texturizar la zona, dando la baja densidad de texels del rage.
en pc se puede configurar para usar atlas y paginas de 8096 y no se si 16k, me suena que recientemente sí. el problema es que las texturas del juego vienen demasiado comprimidas mientras que la megatextura original de epic (todas las paginas juntas) pesaba un terabyte.
las gpus de ps3 y 360 de fábrica estaban limitadas a texturas de 4096 como maximo capando esto.
veo que granite usa 32 mb para una megatextura de 32 gb (todas sus paginas juntas)
me pregunto si se usa un atlas de 16 mb y una página de 16 mb:
“One major benefit from the use of virtual texturing is that you can use much larger textures, even up to 256Kx256K. A texture of that size compressed with DXT1 would occupy 32GB of memory, and loading that texture would take minutes. With Granite, you need only 32MB of VRAM for that texture, and the loading time is unnoticeable.
One thing to take into consideration is that Virtual Texture sampling adds a small performance cost compared to regular texture sampling. We therefore limit the amount of VT textures to 16 per material and a maximum of 4 different UV coordinates to sample those textures. This way, we can make sure that the performance impact of the VT samples is almost unmeasurable in most practical scenarios (e.g., games or VR experiences).”
hablan de “thousand gigapixels” por lo que es multi megatextura, supongo que en un sandbox pasa a usar el atlas y sus páginas de la zona en la que te encuentres, ya que todo esto no deja de ser streaming.
Pues es una buena pregunta, el atlas no es más que una textura lo más grande posible que almacena todas las posibles texturas de la escena y sis mip maps (diferentes tamaños). Dado que en la generación de PS3 y Xbox 360 el tamaño de las texturas era como mucho de 4096×4096 pixeles esto significa que sin compresión de texturas este ocupaba unos 64MB con ellas unos 16MB. En las consolas actuales el tamaño máximo de las texturas es de 16384×16384 por lo que el tamaño que ocupan teniendo en cuenta la compresión de texturas son unos 256MB.
En realidad no necesitas más texturas en cada fotograma que la resolución de renderizado del mismo. En PS2 y Gamecube donde el tamaño del atlas de texturas era como mucho de 512×512 pixeles coincidia casi por completo con la resolución de pantalla pero con la aparición de la cache de texturas en las GPUs de PC por un lado y el aumento del tamaño de las texturas esta práctica desaparecio.
¿Es lo mismo la cache de texturas que el atlas de texturas? Pueden ser lo mismo pero no es lo mismo, el problema es la jerga de «cache de texturas» utilizada para cosas previas a la implementación de una cache propiamente dicha en una GPU, pero en terminos contemporaneos una cache de texturas es:
- Una memoria de pocos KB conectada a las unidades de texturas desde donde realizan el filtraje.
- Los Fragment/Pixel Shaders operan sobre los datos que se encuentran en la cache L1 manipulandolos. En realidad es necesaria una cache de texturas para que hayan Fragment/Pixel Shaders.
- Dicha cache es controlada por hardware y el desarrollador no ha de tocar nada del código para controlar su llenado y vacio de memoria. Es decir, su funcionamiento es transparene al desarrollador.
Tanto en la Sony PlayStation como en la Nintendo 64 se añadió una «cache de texturas» de 2K y 4KB respectivamente con tal de aumentar la tasa de texturizado por un lado y por el otro poder hacer el filtro bilineal sin impacto en la memoria principal y poder utilizar un sistema de memoria de bajo coste. En PC con las Voodoo Graphics primero no se uso cache de texturas sino una memoria muy cara para realizar el filtraje pero el PC ha sido siempre menos sensible al precio. El funcionamiento de las caches contemporaneas es que no almacenan texturas enteras sino quads (2×2 pixeles) porque es con lo que trabajan con los Fragment/Pixel Shaders pero por aquel entonces lo que se hacía era cargar la textura entera, por eso N64 con sus 4KB de texturas tenía problemas graves y en cambio las caches de texturas actuales con 16KB no tienen problemas. La evolucion de N64 fue GameCube que evoluciono la TMEM de N64 de 4KB a 1MB, pero no funciona como una cache contemporanea y sigue cargando las texturas de manera entera, lo mismo ocurre con la evolucion de la primera PlayStation a la segunda, pero en cambio la primera Xbox si que tiene una cache de texturas contemporanea y a partir de esta todas las consolas.
En realidad dichas memorias al estilo de PS2 y GameCube son scratchpads, memorias que deben ser llenadas y vaciadas manualmente desde el código del juego. La idea de tener un scratchpad enorme para almacenar las texturas del fotograma es algo que no es mala idea, simple y llanamente necesitas una memoria capaz de almacenar las texturas utilizadas en el fotograma actual. ¿Se puede hacer? Si, pero no se hace por el hecho que esto sería una cantidad increible de espacio ocupado en los procesadores que se tendría que sacrificar de otros elementos de la GPU, en todo caso la idea de una enorme cache de texturas se ha perdido. ¿Y que ventaja tiene el Atlas entonces estando la cache de texturas enorme entonces? Pues que a la hora de localizar los datos en una cache se perfectamente donde se encuentra la textura no tenemos que hacer que la GPU recorra toda la memoria generando una enorme latencia durante el tiempo de búsqueda y es que aunque las GPUs están pensadas para actuar más por ancho de banda que por latencia llega un punto en que incluso la latencia afecta al rendimiento de la GPU, sobretodo cuando esta ya no puede enmascarar más la latencia con el truco de mantener la GPU ocupada con un flujo continuado de cosas a hacer.
Aunque con la aparición de las memorias HBM, que permiten desglosar los canales de acceso, me pregunto si vamos a ver de nuevo la separación de los buses del ancho de banda, al fin y al cabo con un atlas de texturas sería más que suficiente para la gran mayoría de juegos y se ahorraría mucho en lo que a memoria se refiere, pero mucho.
Disruptive Ludens 
¿has investigado sobre ese plugin del unreal y unity, el granite?
Me gustaMe gusta
No mucho
Me gustaMe gusta
«8 pixels per unreal unit (uu) is a good target for fidelity. The smallest measurement represented in this image is 8x8uu which converts to 64x64pixels. »
1cm=0.7uu, or 1uu=1.43cm
—-
tal y como yo lo entiendo es así:
un atlas de 4096×4096 que cubra el mundo con el menor nivel de mipmap/LOD pondria un color base a cada placa de tamaño 4096 pixeles (no Unreal Units) con cada uno de sus pixeles. al mismo tiempo estaría referenciando una página que aportaría detalle a esa placa al acercarse el personaje, ya que en vez de cargar todas las páginas del nivel solo se cargarian las cercanas.
Ahí interviene un streaming constante de páginas de mayor o menor calidad de mipmap según la distancia.
si solo estuviera cargado el atlas y una página (ambos de 4k de lado, compresión 1:4 y 4 bytes x pixel), juntos ocuparian 32 mb.
pero me extraña que con solo una página de 4096 para la zona se vea bien. desde luego Rage no, y en pc la gente lo tiene que configurar minimo en páginas de 8096, aunque el otro problema es la alta compresión con pérdida por utilizar un lienzo gigante de un terabyte en vez de una biblioteca de texturas.
supongo que se puede optar entre varias páginas (por ejemplo la del personaje con él en el centro y 9 alrrededor) o abarcar todo el LOD salvo el menor nivel de detalle con una única página.
supongamos que la página de 4096 incluye mipmaps, entonces en la practica es de 2048 de lado…. o usar páginas de 8k que con mipmaps equivale a 2 texturas 4k.
puede que baste teniendo en cuenta cuantos pixeles puede mostrar a la vez la pantalla, pero entonces me acuerdo del poping de texturas de rage en cuanto te das media vuelta y digo NOP!
iD siempre utiliza 90 grados de FOV así que para evitar poping al girarte harían falta 4 páginas simultáneas. o para aumentar la densidad de texels y hacerlo mas facil, lo que dije antes, una página central con el menor LOD y una de distancia envolviendo al jugador, 10 en total.si las páginas son de 4k con mipmaps siendo de 2k el trozo de mayor calidad.
eso serían 16 mb + 160 = 176 para texturas. o con páginas 8k (el trozo mas grande de 8k x 4k), 16 + 640 = 656 mb.
eso me lleva a lo que dijo el de granite de «entre 512 mb y 1024 en total con resolución full hd».
el asunto es que rage basicamente usa la megatextura como pintura para el escenario, mientras que granite puede usarla para importar la biblioteca de texturas
si es como yo digo, esas 10 páginas 8k podrian incluir 20 texturas 4k con sus mipmaps hasta el menor nivel (y el del atlas sería el color base antes de cargar la página) usando los mipmaps para los objetos lejanos y usando 20 texturas en total para la escena, lo cual es poquísimo si no se usa al estilo Rage.
en cambio serían 80 texturas 1024×1024 para la escena, contando con que se usan varias para muchos materiales, algo mas razonable en cuanto a la cantidad pero no en un sandbox o con un ejército. de ellas habria que restar unas cuantas para el suelo y paredes grandes que si suelen usar 2048×2048 o 4096×4096 así que iria muy justito.
creo que lo suyo serían 10 páginas de 16k, sería lo anterior en resolucion 4k directamente, y se liberaría espacio para aumentar la cantidad en un sandbox reduciendo la resolucion de texturas maxima a 2048 o 1024 segun el objeto que se texturice.
eso con el atlas sumaria 2576 mb, sin poping de texturas al girarte ni pérdida de calidad apreciable por usar megatexturas, sin limitacion de diversidad de texturas en sandbox (y si no, se sacrifica resolucion de algunas y se repiten mas en mosaico)
y este es el uso de vram de doom que usa megatexturas mejoradas, pero incluyendo shadowmaps:
y es que todo esto era en el supuesto de texturizar solo el color base de los materiales (el canal diffuse en unreal) pero es que habria que dividir entre 4 la resolucion efectiva en las páginas por usar color, normal maps, displacement maps (esos 3 en la megatextura de granite) y también la textura de iluminacion precalculada, el shadowmap (que granite tambien genera como megatextura para el lightmass pero va por separado)
por otra parte podemos asignar mucha menos importancia a los shadowmaps. en unity por defecto se usan dos de 2048×2048 y supongo que quiere decir mipmapping a 2k. eso como megatextura serían 4+4 mb con una página por zona del jugador (poping de sombras?) o 44 mb con lo de las 10 páginas. suponiendo que sea poco para un AAA de pc y consola de sobremesa, serían 164 mb en calidad 4k.
total, gpus de 3 gb, y en teoria no hace falta mas, porque a partir de ahí es todo streaming
podrian usar hbm de 4 gb como algo estandar (aportando retrocompatibilidad con juegos actuales) en consolas futuras y lo demas ram barata y abundante, en plan 16 gb con 4 reservados y 4 para grabacion 4k.
para entonces los lectores opticos deberian poder alimentar 3 o 4 gb (la hbm) en un sandbox con este nivel de calidad, no se si con blurays o holograficos o que, para evitar instalaciones gigantes
Me gustaMe gusta