La necesidad de recursos de streaming

Se necesitan recursos de streaming 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.

Streaming de recursos 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 la naturaleza en mosaico de los recursos, así como quizás la razón principal de la creación de mosaicos, 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 de Direct3D en granularidad de subrecursos.

Para un búfer, todo el búfer es el subrecurso.

En el caso de texture, (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 de gráficos solo expone la capacidad de administrar la asignación de asignaciones en esta granularidad de subrecursos. En el contexto de los recursos de streaming, "asignación" hace referencia a hacer que los datos sean visibles para la GPU.

Sin mosaico, no puede acceder solo a una pequeña parte de la cadena mipmap.

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 mapas 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 de gráficos solo se molestaría en 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 de gráficos, 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 de gran tamaño 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 en 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.

Un inconveniente significativo de ese enfoque proviene del hardware que no sabe nada sobre la paginación que está ocurriendo: cuando una parte de una imagen debe mostrarse en la pantalla que separa iconos, el hardware no sabe cómo realizar un filtrado fijo de funciones (es decir, eficiente) 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 convierte en muy caro si se desea un filtro anisotrópico de buena calidad) o desperdiciar canalizaciones de memoria que contienen datos de mosaicos vecinos para que el filtrado fijo de hardware de función pueda seguir proporcionando cierta ayuda.

Hacer una representación en mosaico de las asignaciones de superficies una característica de primera clase

Si una representación en mosaico de las asignaciones de superficies 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 la aplicación sabe que no se accederá, y el hardware puede comprender cómo filtrar entre iconos adyacentes, lo que alivia parte del dolor experimentado por los desarrolladores que realizan mosaicos de software por sí mismos.

Pero para proporcionar una solución completa, debe hacerse algo para tratar con el hecho de que, independientemente de si se admite el mosaico dentro de una superficie, la dimensión de superficie máxima es actualmente 16384, en ningún lugar cerca de los 128K+ que las aplicaciones ya quieren. 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 en la compatibilidad con texturas de 16 000 con los demás requisitos, como admitir extensiones de ventanilla que caen de la superficie durante la representación o admitir el ajuste de textura fuera del borde de la superficie durante el filtrado. Una posibilidad es definir un equilibrio, de modo que, como el tamaño de textura aumenta más allá de 16 000, la funcionalidad y la precisión se renuncian 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 llegar 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 se hacen muy grandes es que las coordenadas de textura de punto flotante de precisión única (y los interpoladores asociados para admitir la rasterización) se agota la precisión para especificar ubicaciones en la superficie con precisión. El filtrado de texturas jittery se ensuería. Una opción costosa sería requerir compatibilidad con el interpolador de doble precisión, aunque esto podría ser excesivamente dado una alternativa razonable.

Habilitación de varios recursos de diferentes dimensiones para compartir memoria

Otro escenario que los recursos de streaming podrían servir 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 solo se crean 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 puede desacoplar desde la administración de la memoria subyacente a los recursos desde el punto de vista de la aplicación.

Recursos de streaming