La necesidad de recursos de streaming
Los recursos de streaming son necesarios para que no se pierda la memoria de GPU almacenando regiones de superficies a las que no se accederá y para indicar al hardware cómo filtrar entre iconos adyacentes.
Recursos de streaming o texturas dispersas
Los recursos de streaming (denominados recursos en mosaico en Direct3D 11), son recursos lógicos grandes que usan pequeñas cantidades de memoria física.
Otro nombre para los recursos de streaming es texturas dispersas. "Disperso" transmite tanto la naturaleza en mosaico de los recursos como quizás la razón principal para ponerlas en mosaico, que no se espera que todos ellos se asignen a la vez. De hecho, una aplicación podría crear concebiblemente un recurso de streaming en el que no se crea ningún dato para todas las regiones+mips del recurso, intencionadamente. Por lo tanto, el propio contenido podría ser disperso y la asignación del contenido en la memoria de la unidad de procesamiento de gráficos (GPU) en un momento dado sería un subconjunto de eso (aún más disperso).
Sin mosaicos, las asignaciones de memoria se administran en granularidad de subrecursos.
En un sistema gráfico (es decir, el sistema operativo, el controlador de pantalla y el hardware gráfico) sin compatibilidad con recursos de streaming, el sistema gráfico administra todas las asignaciones de memoria direct3D en granularidad de subrecursos.
Para un búfer, todo el búfer es el subrecurso.
Para una textura( por ejemplo, Texture2D), cada nivel mip es un subrecurso; para una matriz de texturas( por ejemplo, Texture2DArray) cada nivel mip en un segmento de matriz determinado es un subrecurso. El sistema gráfico solo expone la capacidad de administrar la asignación de asignaciones en esta granularidad de subrecursos. En el contexto de los recursos de streaming, la "asignación" hace referencia a hacer que los datos sean visibles para la GPU.
Sin mosaicos, no puede acceder solo a una pequeña parte de la cadena de mapas mip
Supongamos que una aplicación sabe que una operación de representación determinada solo necesita tener acceso a una pequeña parte de una cadena de mapa mip de imagen (quizás ni siquiera el área completa de un mapa mip determinado). Idealmente, la aplicación podría informar al sistema de gráficos sobre esta necesidad. El sistema gráfico solo se molestaría para asegurarse de que la memoria necesaria se asigna en la GPU sin paginar demasiado memoria.
En realidad, sin compatibilidad con recursos de streaming, el sistema de gráficos solo se puede informar sobre la memoria que debe asignarse en la GPU en granularidad de subrecursos (por ejemplo, un intervalo de niveles de mapa mip completos a los que se puede acceder). Tampoco hay errores de demanda en el sistema gráfico, por lo que potencialmente se debe usar una gran cantidad de memoria GPU excesiva para hacer que se asignen subrecursos completos antes de que se ejecute un comando de representación que haga referencia a cualquier parte de la memoria. Este es solo un problema que dificulta el uso de asignaciones de memoria grandes en Direct3D sin compatibilidad con recursos de streaming.
Paginación de software para dividir la superficie en iconos más pequeños
La paginación de software se puede usar para dividir la superficie en mosaicos lo suficientemente pequeños como para que el hardware lo controle.
Direct3D admite superficies Texture2D con hasta 16384 píxeles en un lado determinado. Una imagen de 16384 de ancho por 16384 de alto y 4 bytes por píxel consumiría 1 GB de memoria de vídeo (y agregar mapas mip duplicaría esa cantidad). En la práctica, rara vez es necesario hacer referencia a todos los 1 GB en una sola operación de representación.
Algunos desarrolladores de juegos modelar superficies de terreno tan grandes como 128 000 por 128 000. La forma en que pueden trabajar en GPU existentes es dividir la superficie en mosaicos lo suficientemente pequeños como para que el hardware lo controle. La aplicación debe averiguar qué iconos podrían ser necesarios y cargarlos en una caché de texturas en la GPU: un sistema de paginación de software.
Una desventaja significativa de ese enfoque proviene del hardware que no sabe nada sobre la paginación que está ocurriendo: Cuando es necesario mostrar una parte de una imagen en la pantalla que separa iconos, el hardware no sabe cómo realizar el filtrado fijo de funciones (es decir, eficientes) entre mosaicos. Esto significa que la aplicación que administra su propio mosaico de software debe recurrir al filtrado manual de texturas en el código del sombreador (que se vuelve muy caro si se desea un filtro anisotrópico de buena calidad) o los canalones de creación de memoria de desecho alrededor de los mosaicos que contienen datos de iconos vecinos para que el filtrado de hardware de función fija pueda seguir proporcionando cierta ayuda.
Hacer una representación en mosaico de las asignaciones de superficies de una característica de primera clase
Si una representación en mosaico de las asignaciones de superficie es una característica de primera clase en el sistema gráfico, la aplicación podría indicar al hardware qué iconos poner a disposición. De este modo, se desperdicia menos memoria de GPU almacenando regiones de superficies a las que no se accede a la aplicación y el hardware puede entender cómo filtrar por iconos adyacentes, lo que alivia parte del dolor que experimentan los desarrolladores que realizan la creación de mosaicos de software por sí mismos.
Pero para proporcionar una solución completa, se debe hacer algo para tratar con el hecho de que, independientemente de si se admite la colocación en mosaico dentro de una superficie, la dimensión máxima de superficie es actualmente 16384, en ninguna parte cerca de los 128K+ que las aplicaciones ya desean. La necesidad de que el hardware admita tamaños de textura más grandes es un enfoque, pero hay costos significativos o inconvenientes para ir a esta ruta.
La ruta de acceso de filtro de textura y la ruta de representación de Direct3D ya están saturadas en términos de precisión para admitir texturas de 16 000 con los demás requisitos, como admitir extensiones de ventanilla que caen de la superficie durante la representación o el ajuste de texturas fuera del borde de la superficie durante el filtrado. Una posibilidad es definir un equilibrio, como que el tamaño de textura aumenta más allá de 16 000, la funcionalidad y la precisión se entregan de alguna manera. Sin embargo, incluso con esta concesión, es posible que se requieran costos adicionales de hardware en términos de capacidad de direccionamiento en todo el sistema de hardware para ir a tamaños de textura más grandes.
Problema con texturas grandes: precisión para ubicaciones en la superficie
Un problema que entra en juego a medida que las texturas obtienen un tamaño muy grande es que las coordenadas de textura de punto flotante de precisión única (y los interpoladores asociados para admitir la rasterización) se ejecutan sin precisión para especificar ubicaciones en la superficie con precisión. El filtrado de texturas jittery se produciría. Una opción costosa sería requerir compatibilidad con el interpolador de precisión doble, aunque esto podría ser excesivamente dado una alternativa razonable.
Habilitación de varios recursos de diferentes dimensiones para compartir memoria
Otro escenario que podrían servir los recursos de streaming es permitir que varios recursos de diferentes dimensiones o formatos compartan la misma memoria. A veces, las aplicaciones tienen conjuntos exclusivos de recursos que se sabe que no se usan al mismo tiempo, o recursos que se crean solo para un uso muy breve y, a continuación, se destruyen, seguidos de la creación de otros recursos. Una forma de generalidad que puede salir de "recursos de streaming" es que es posible permitir que el usuario apunte a varios recursos diferentes en la misma memoria (superpuesta). Es decir, la creación y destrucción de "recursos" (que definen una dimensión o formato, etc.) se pueden desacoplar desde la administración de la memoria subyacente a los recursos desde el punto de vista de la aplicación.
Temas relacionados