estructura D3D12_FEATURE_DATA_ARCHITECTURE1 (d3d12.h)
Proporciona detalles sobre los detalles de la arquitectura 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 iconos. El tiempo de ejecución establece este miembro en TRUE si el hardware y el controlador admiten un representador basado en iconos.
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, consulte Constantes de protección de memoria).
Si 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 inspección de escritura pueden aparecer sucias, incluso cuando no es obvio cómo las escrituras de GPU pueden haberlas afectado. Las operaciones de GPU asociadas a escenarios de uso del montón de carga y lectura funcionan bien con páginas de inspección de escritura, pero en ocasiones pueden generar falsos positivos que se pueden omitir de forma segura.
Observaciones
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 los presupuestos de memoria del sistema y de memoria de vídeo. Si el tamaño de los montones de carga rivaliza con el tamaño de las texturas predeterminadas, hay disponible una duplicación casi del uso de memoria. Al admitir estas optimizaciones, una aplicación puede detectar dos presupuestos de residencia o reconocer 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 los 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 se beneficia normalmente de las tres atribución de montón. Existen oportunidades para quitar la copia de recursos a través del uso adecuado de los recursos de carga y lectura y los montones, que proporcionan acceso a la CPU a la memoria. Sin embargo, estas oportunidades no son claras. Por lo tanto, las aplicaciones deben ser cautelosas; y la experimentación en una variedad de sistemas "UMA" es aconsejable, ya que se puede garantizar la posibilidad de habilitar o descartar determinados identificadores de dispositivo. Se recomienda comprender la arquitectura de memoria de GPU y cómo se recomiendan los tipos de montón a 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 los datos, etcetera. 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 información.
Cuando cacheCoherentUMA es cierto, las aplicaciones pueden entretener mucho más abandonar la atribución de montones y usar el equivalente de montón personalizado de montón de carga en todas partes. Las optimizaciones de UMA de copia cero, como las ofrecidas por WriteToSubresource, se recomienda 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 existir en los que las ventajas no se obtienen fácilmente, pero deben ser mucho más raras 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 están unificadas o integradas entre la CPU y la GPU. La característica observable más única es que los montones de carga se vuelven a escribir en CacheCoherentUMA. Para esta arquitectura, el uso de la combinación de escritura en los montones de carga suele ser perjudicial.
La mayoría de las aplicaciones de adaptador único deben omitir los detalles de bajo nivel. Como de costumbre, las aplicaciones de adaptador único pueden simplificar el panorama y asegurarse de que las escrituras de CPU para cargar montones usan patrones que son descriptivos para 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 de montón personalizadas óptimas para mover datos de forma eficaz entre adaptadores.
Requisitos
| Requisito | Valor |
|---|---|
| encabezado de |
d3d12.h |
Consulte también
estructuras principales de