Compartir a través de


Alias de memoria y herencia de datos

Los recursos colocados y reservados pueden ser alias de memoria física dentro de un montón. Los recursos colocados permiten más escenarios de herencia de datos que los recursos reservados cuando el montón tiene establecida la marca compartida o cuando los recursos con alias tienen diseños de memoria totalmente definidos.

Establecimiento de alias

Se debe emitir una barrera de alias entre el uso de dos recursos que comparten la misma memoria física, incluso si no se desea la herencia de datos. Los modelos de uso simples deben indicar, al menos, el recurso de destino implicado en dicha operación. Consulte CreatePlacedResource para obtener más detalles y modelos de uso avanzados.

Después de acceder a un recurso, los recursos que comparten la memoria física con ese recurso se invalidan, a menos que se permita la herencia de datos. Las lecturas de los recursos invalidados dan como resultado contenido de recursos no definidos. Las escrituras en recursos invalidados también dan lugar a contenido de recursos no definido, a menos que se produzcan dos condiciones:

  • El recurso no tiene D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET o D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL.
  • La escritura es una operación de copia o borrado en un subrecurso o mosaico completo. La inicialización de mosaicos solo está disponible para los recursos con 64KB_TILE_UNDEFINED_SWIZZLE y 64KB_TILE_STANDARD_SWIZZLE.

Las invalidaciones por superposición se limitan a granularidades más pequeñas, cuando los diseños proporcionan información sobre la ubicación en la ubicación de los datos de elementos de textura y cuando los recursos se encuentran en determinados estados de barrera de transición. Sin embargo, las invalidaciones no pueden ser más pequeñas que las granularidades de alineación de recursos.

Una granularidad de alineación del búfer es de 64 KB y la granularidad de alineación más grande tiene prioridad. Esto es importante al considerar texturas de 4 KB, ya que varias texturas de 4 KB pueden residir en una región de 64 KB sin superponerse entre sí. Pero no se puede usar un alias de búfer de la misma región de 64 KB junto con ninguna de esas texturas de 4 KB. La aplicación no puede mantener de forma confiable el acceso al búfer desde la intersección de las texturas de 4 KB, ya que las GPU pueden hacer referencia a datos de textura de 4KB dentro de la región de 64 KB en un patrón indefinido.

Los diseños de textura 64KB_TILE_UNDEFINED_SWIZZLE, 64KB_TILE_STANDARD_SWIZZLE y ROW_MAJOR informan a la aplicación de qué granularidades de alineación superpuestas se han convertido en no válidas. Por ejemplo: una aplicación puede crear una matriz de texturas de destino de representación 2D con 2 segmentos de matriz, un solo nivel mip y el diseño 64KB_TILE_UNDEFINED_SWIZZLE. Supongamos que la aplicación sabe que cada segmento de matriz ocupa 100 mosaicos de 64 KB. La aplicación puede renunciar a utilizar el sector de matriz 0 y volver a usar esa memoria para un búfer de ~6 MB, una textura de ~6 MB con diseño indefinido, etc. En adelante, supongamos que la aplicación ya no requiere el primer mosaico del sector de matriz 1. A continuación, la aplicación también podría ubicar un búfer de 64 KB allí hasta que la representación requiera de nuevo el primer mosaico del sector de matriz 1. La aplicación tendría que hacer una copia o borrar un mosaico completo para volver a usar el primer mosaico con la matriz de texturas de nuevo.

Sin embargo, incluso las texturas con diseños definidos siguen teniendo casos problemáticos. Los tamaños de los recursos de texturas pueden diferir significativamente de lo que la aplicación puede calcular por sí misma, ya que algunas arquitecturas de adaptadores asignan memoria adicional a las texturas para reducir el ancho de banda efectivo durante los escenarios de representación habituales. Las invalidaciones en esa región de memoria adicional hacen que todo el recurso se invalide. Consulte GetResourceAllocationInfo para obtener más información.

Herencia de datos

Los recursos colocados permiten la mayor herencia de datos para las texturas, incluso con diseños de memoria no definidos. Las aplicaciones pueden imitar las funcionalidades de herencia de datos que permiten los recursos confirmados compartidos mediante la búsqueda de dos texturas con propiedades de recursos idénticas en el mismo desplazamiento en un montón compartido. Toda la descripción del recurso debe ser idéntica, incluido el valor claro optimizado y el tipo de método de creación de recursos (colocados o reservados). Sin embargo, ambos recursos pueden haber tenido diferentes estados de barrera de transición inicial.

Los recursos reservados permiten la herencia de datos por mosaico; pero suele haber restricciones para los estados de barrera de transición de recursos.

Para heredar datos, ambos recursos deben estar en un estado de barrera de transición de recursos compatible:

  • En el caso de los búferes, las texturas de acceso simultáneo y las texturas entre adaptadores, el estado de transición de recursos no es importante y todos los estados son "compatibles".
  • En el caso de las texturas reservadas sin las propiedades anteriores u otra herencia de datos por mosaico a través de 64KB_TILE_UNDEFINED_SWIZZLE o 64KB_TILE_STANDARD_SWIZZLE, el estado de barrera de transición de recursos, incluido el mosaico, debe estar en estado común.
  • Para todas las demás texturas, donde las descripciones de recursos coinciden exactamente, el estado de barrera de transición de recursos para cada par correspondiente de subrecursos debe:
    • Estar en estado común.
    • Ser igual que cuando el estado tiene la misma marca de escritura de GPU en ellos.

Cuando la GPU admite referencia estándar, los búferes y las texturas de referencia estándar pueden tener un alias en la misma memoria y heredar datos entre ellos. La aplicación puede manipular los elementos de textura de la representación del búfer, ya que el patrón de referencia estándar describe cómo se diseñan los elementos de textura en la memoria. El patrón de referencia visible para CPU es equivalente al patrón de referencia visible para GPU que se ve en los búferes.

Subasignación en los búferes