estructura D3D12_FEATURE_DATA_ARCHITECTURE1 (d3d12.h)
Proporciona detalles sobre los detalles arquitectónicos de cada adaptador para que la aplicación pueda optimizar mejor determinadas propiedades del adaptador.
Sintaxis
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE1 {
UINT NodeIndex;
BOOL TileBasedRenderer;
BOOL UMA;
BOOL CacheCoherentUMA;
BOOL IsolatedMMU;
} D3D12_FEATURE_DATA_ARCHITECTURE1;
Miembros
NodeIndex
En la operación de varios adaptadores, esto indica qué adaptador físico del dispositivo es relevante. Consulte Sistemas de varios adaptadores. NodeIndex se rellena mediante la aplicación antes de llamar a CheckFeatureSupport, ya que la aplicación puede recuperar detalles sobre la arquitectura de cada adaptador.
TileBasedRenderer
Especifica si el hardware y el controlador admiten un representador basado en mosaicos. El tiempo de ejecución establece este miembro en TRUE si el hardware y el controlador admiten un representador basado en mosaicos.
UMA
Especifica si el hardware y el controlador admiten UMA. El tiempo de ejecución establece este miembro en TRUE si el hardware y el controlador admiten UMA.
CacheCoherentUMA
Especifica si el hardware y el controlador admiten UMA coherente con la memoria caché. El tiempo de ejecución establece este miembro en TRUE si el hardware y el controlador admiten UMA coherente con la memoria caché.
IsolatedMMU
SAL: Out
Especifica si el hardware y el controlador admiten la unidad de administración de memoria aislada (MMU). El tiempo de ejecución establece este miembro en TRUE si la GPU respeta las propiedades de la tabla de páginas de CPU como MEM_WRITE_WATCH (para obtener más información, consulte VirtualAlloc) y PAGE_READONLY (para obtener más información, vea Constantes de protección de memoria).
Si es TRUE, la aplicación debe tener cuidado de no usar memoria con estas propiedades de tabla de páginas con la GPU, ya que la GPU podría desencadenar estas propiedades de tabla de páginas de maneras inesperadas. Por ejemplo, las operaciones de escritura de GPU pueden ser más gruesas que las que espera la aplicación, especialmente las escrituras desde los sombreadores. Algunas páginas de watch de escritura pueden aparecer sucias, incluso cuando no es obvio cómo las escrituras de GPU pueden haber afectado. Las operaciones de GPU asociadas con escenarios de uso del montón de carga y de lectura diferida funcionan bien con páginas de watch de escritura, pero en ocasiones pueden generar falsos positivos que se pueden omitir de forma segura.
Comentarios
Cómo usar UMA y CacheCoherentUMA
Las aplicaciones D3D12 deben preocuparse por administrar la residencia de memoria y proporcionar las propiedades óptimas del montón. Las aplicaciones D3D12 pueden simplificarse y ejecutarse razonablemente bien en muchas arquitecturas de GPU mediante la administración de la residencia de recursos en D3D12_HEAP_TYPE_DEFAULT montones. Esas aplicaciones solo necesitan llamar a IDXGIAdapter3::QueryVideoMemoryInfo para DXGI_MEMORY_SEGMENT_GROUP_LOCAL, y deben ser tolerantes a que D3D12_HEAP_TYPE_UPLOAD y D3D12_HEAP_TYPE_READBACK provengan de ese mismo grupo de segmentos de memoria.Sin embargo, un diseño tan sencillo es demasiado restringido para las aplicaciones que insertan los límites. Por lo tanto, D3D12_FEATURE_DATA_ARCHITECTURE ayuda a las aplicaciones a optimizar mejor las propiedades del adaptador subyacente.
Es posible que algunas aplicaciones quieran optimizar mejor los adaptadores discretos y asumir la complejidad adicional de administrar presupuestos de memoria del sistema y memoria de vídeo. Si el tamaño de los montones de carga rivaliza con el tamaño de las texturas predeterminadas, está disponible una duplicación casi del uso de memoria. Al admitir estas optimizaciones, una aplicación puede detectar dos presupuestos de residencia o reconocer que UMA es false.
Es posible que algunas aplicaciones quieran optimizar mejor los adaptadores integrados o UMA, especialmente aquellos que están interesados en extender la duración de la batería en el dispositivo móvil. Las aplicaciones D3D12 simples se ven forzadas a copiar datos entre montones con diferentes atribución, cuando no siempre es necesario en UMA. Sin embargo, la propiedad UMA, por sí misma, abarca un área gris razonablemente vaga de diseños de GPU. No suponga que UMA significa que toda la memoria accesible para GPU puede ser accesible libremente a la CPU, ya que no lo hace. Hay una propiedad que se alinea más estrechamente con ese tipo de pensamiento: CacheCoherentUMA.
Cuando CacheCoherentUMA es false, hay disponible un único presupuesto de residencia, pero el diseño de UMA suele beneficiarse de las tres atribución del montón. Existen oportunidades para quitar la copia de recursos a través del uso correcto de los recursos de carga y lectura y montones, que proporcionan acceso a la CPU a la memoria. Sin embargo, esas oportunidades no son claras. Por lo tanto, las aplicaciones deben ser cautelosas; y la experimentación en una variedad de sistemas de "UMA" es aconsejable, ya que es posible garantizar la habilitación o la inclusión de determinados identificadores de dispositivo. Se recomienda comprender la arquitectura de memoria de GPU y cómo se traducen los tipos de montón en las propiedades de caché. Es probable que la viabilidad del éxito dependa de la frecuencia con la que cada procesador lee o escribe los datos, el tamaño y la localidad de los accesos a datos, etc. Para desarrolladores avanzados: cuando UMA es true y CacheCoherentUMA es false, la característica más única para estos adaptadores es que los montones de carga siguen siendo combinados de escritura. Sin embargo, algunos adaptadores de UMA se benefician de las propiedades sin acceso a CPU y escritura-combine de los montones predeterminados y de carga. Consulte GetCustomHeapProperties para obtener más detalles.
Cuando CacheCoherentUMA es true, las aplicaciones pueden entretener mucho más abandonar la atribución de montones y usar el equivalente de montón personalizado de montones de carga en todas partes. Las optimizaciones de UMA de copia cero, como las que ofrece WriteToSubresource , se animan más generalmente, ya que más escenarios solo se beneficiarán del uso compartido. El modelo de memoria es muy favorable a más escenarios y a una adopción más amplia. Algunos casos de esquina pueden seguir existiendo en los que los beneficios no se obtienen fácilmente, pero deben ser mucho más raros y menos perjudiciales que otras opciones. Para desarrolladores avanzados: CacheCoherentUMA significa que una cantidad significativa de las memorias caché de la jerarquía de memoria también se unifican o integran entre la CPU y la GPU. La característica observable más única es que los montones de carga son realmente reescritura en CacheCoherentUMA. Para esta arquitectura, el uso de combinación de escritura en montones de carga suele ser un perjuicio.
La mayoría de las aplicaciones de adaptador único deben omitir los detalles de bajo nivel. Como de costumbre, las aplicaciones de un solo adaptador pueden simplificar el panorama y asegurarse de que las escrituras de CPU para cargar montones usan patrones que admiten escritura y combinación. Los detalles de nivel inferior ayudan a reforzar los conceptos de las aplicaciones de varios adaptadores. Es probable que las aplicaciones de varios adaptadores necesiten comprender las propiedades de la arquitectura del adaptador lo suficientemente bien como para elegir las propiedades óptimas del montón personalizado para mover datos entre adaptadores de forma eficaz.
Requisitos
| Requisito | Valor |
|---|---|
| Header | d3d12.h |
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de