Compartir a través de

Residencia

  • Artículo

Un objeto se considera residente cuando es accesible por la GPU.

Presupuesto de residencia

Las GPU aún no admiten errores de página, por lo que las aplicaciones deben confirmar datos en memoria física mientras la GPU podría acceder a ella. Este proceso se conoce como "hacer algo residente" y debe realizarse tanto para la memoria física del sistema como para la memoria de vídeo discreta física. En D3D12, la mayoría de los objetos de API encapsulan cierta cantidad de memoria accesible para GPU. Esa memoria accesible para GPU se convierte en residente durante la creación del objeto de API y se expulsa en la destrucción de objetos de API.

La cantidad de memoria física disponible para el proceso se conoce como presupuesto de memoria de vídeo. El presupuesto puede fluctuar notablemente a medida que los procesos en segundo plano se reactivan y duermen; y fluctúan drásticamente cuando el usuario pasa a otra aplicación. La aplicación se puede notificar cuando el presupuesto cambia y sondea tanto el presupuesto actual como la cantidad de memoria consumida actualmente. Si una aplicación no permanece dentro de su presupuesto, el proceso se inmovilizará intermitentemente para permitir que otras aplicaciones se ejecuten o las API de creación devolverán un error. La interfaz IDXGIAdapter3 proporciona los métodos relacionados con esta funcionalidad, en particular QueryVideoMemoryInfo y RegisterVideoMemoryBudgetChangeNotificationEvent.

Se recomienda que las aplicaciones usen una reserva para indicar la cantidad de memoria que no pueden pasar sin. Idealmente, la configuración de gráficos "baja" especificada por el usuario, o algo incluso inferior, es el valor adecuado para dicha reserva. Establecer una reserva nunca dará a una aplicación un presupuesto superior al que normalmente recibiría. En su lugar, la información de reserva ayuda al kernel del sistema operativo a minimizar rápidamente el impacto de situaciones de presión de memoria de gran tamaño. Incluso no se garantiza que la reserva esté disponible para la aplicación cuando la aplicación no sea la aplicación en primer plano.

Recursos del montón

Aunque muchos objetos de API encapsulan cierta memoria accesible para GPU, se espera que los & recursos del montón sean la forma más importante en que las aplicaciones consumen y administran la memoria física. Un montón es la unidad de nivel más bajo para administrar la memoria física, por lo que es bueno tener cierta familiaridad con sus propiedades de residencia.

  • No se pueden realizar montones parcialmente residentes, pero existen soluciones alternativas con recursos reservados.
  • Los montones deben presupuestarse como parte de un grupo determinado. Los adaptadores de UMA tienen un grupo, mientras que los adaptadores discretos tienen dos grupos. Aunque es cierto que el kernel puede cambiar algunos montones en adaptadores discretos de memoria de vídeo a memoria del sistema, solo lo hace como un último recurso extremo. Las aplicaciones no deben confiar en el comportamiento sobre presupuesto del kernel y deben centrarse en una buena administración del presupuesto en su lugar.
  • Los montones se pueden expulsar de la residencia, lo que permite paginar su contenido en el disco. Sin embargo, la destrucción de montones es una técnica más confiable para liberar la residencia en todas las arquitecturas de adaptador. En los adaptadores en los que el campoMaxGPUVirtualAddressBitsPerProcess de D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT está cerca del tamaño del presupuesto, Evict no reclamará de forma confiable la residencia.
  • La creación del montón puede ser lenta; pero está optimizado para el procesamiento de subprocesos en segundo plano. Se recomienda crear montones en subprocesos en segundo plano para evitar deslizar el subproceso de representación. En D3D12, varios subprocesos pueden llamar de forma segura a las rutinas de creación simultáneamente.

D3D12 presenta más flexibilidad y ortogonalidad en su modelo de recursos para habilitar más opciones para las aplicaciones. Hay tres tipos de recursos de alto nivel en D3D12: confirmados, colocados y reservados.

  • Los recursos confirmados crean un recurso y un montón al mismo tiempo. El montón es implícito y no se puede acceder directamente a él. El montón tiene el tamaño adecuado para localizar todo el recurso dentro del montón.
  • Los recursos colocados permiten colocar un recurso en un desplazamiento distinto de cero dentro de un montón. Los desplazamientos normalmente deben alinearse con 64 KB; pero algunas excepciones existen en ambas direcciones. Los recursos de MSAA requieren alineación de desplazamiento de 4 MB y la alineación de desplazamiento de 4 KB está disponible para texturas pequeñas. Los recursos colocados no se pueden reubicar ni reasignar directamente a otro montón; pero permiten la reubicación simple de los datos de recursos entre montones. Después de crear un nuevo recurso colocado en un montón diferente y copiar los datos del recurso, los nuevos descriptores de recursos tendrán que usarse para la nueva ubicación de datos de recursos.
  • Los recursos reservados solo están disponibles cuando el adaptador admite el nivel de recursos en mosaico 1 o superior. Cuando están disponibles, ofrecen las técnicas de administración de residencia más avanzadas disponibles; pero no todos los adaptadores actualmente los admiten. Permiten reasignar un recurso sin necesidad de regeneración de descriptores de recursos, residencia parcial de nivel mip y escenarios de textura dispersa, etc. No todos los tipos de recursos se admiten incluso cuando los recursos reservados están disponibles, por lo que aún no es factible un administrador de residencia basado en páginas totalmente general.

Prioridades de residencia

El Windows 10 Creators Update permite a los desarrolladores influir en qué montones y recursos se prefieren permanecer residentes cuando la presión de memoria requiere que se degradan algunos de sus recursos. Esto ayuda a los desarrolladores a crear aplicaciones de mejor rendimiento aprovechando el conocimiento que el tiempo de ejecución no puede deducir del uso de la API. Se espera que los desarrolladores se vuelvan más cómodos y capaces de especificar prioridades a medida que pasan del uso de recursos comprometidos para volver a serreveados y recursos en mosaico.

Aplicar estas prioridades debe ser más fácil que administrar dos presupuestos de memoria dinámica, reducir manualmente y promover los recursos entre ellos, ya que las aplicaciones ya pueden hacerlo. Por lo tanto, el diseño de la API de prioridad de residencia está por supuesto específico con prioridades predeterminadas razonables asignadas a cada montón o recurso según se cree. Para obtener más información, vea ID3D12Device1::SetResidencyPriority y la enumeración D3D12_RESIDENCY_PRIORITY .

Con prioridades, se espera que los desarrolladores:

  • Aumente la prioridad de algunos montones excepcionales para mitigar mejor el impacto en el rendimiento experimentado de estos montones que se degradan antes o con más frecuencia que sus patrones de acceso natural demandarían. Se espera que las aplicaciones portados desde API de gráficos como Direct3D 11 o OpenGL aprovechen este enfoque, que el modelo de administración de recursos es significativamente diferente al de Direct3D 12.
  • Invalide casi todas las prioridades del montón con el propio esquema de bucketization de la aplicación, ya sea fijo, en función del conocimiento de la frecuencia de acceso del programador o dinámico; Un esquema fijo es más sencillo de administrar que uno dinámico, pero puede ser menos eficaz y requerir la invención del programador a medida que cambian los patrones de uso durante el desarrollo. Se espera que las aplicaciones que se compilan con la administración de recursos de estilo Direct3D 12 se aprovechen en mente, como las que usan la biblioteca de residencia (especialmente los esquemas dinámicos).

Algoritmo de prioridad predeterminado

Una aplicación no puede especificar prioridades útiles para ningún montón que intente administrar sin substanir primero el algoritmo de prioridad predeterminado. Esto se debe a que el valor de asignar una prioridad determinada a un montón se deriva de su prioridad relativa a otros montones priorizados que compiten por la misma memoria.

La estrategia elegida para generar prioridades predeterminadas consiste en clasificar los montones en dos cubos, lo que favorece (dando prioridad más alta a) los montones que se supone que la GPU escribe con frecuencia sobre montones que no lo son.

El cubo de prioridad alta contiene montones y recursos creados con marcas que los identifican como destinos de representación, búferes de galería de símbolos de profundidad o Vistas de acceso sin ordenar (UAV). Se les asignan valores de prioridad en el intervalo a partir de D3D12_RESIDENCY_PRIORITY_HIGH; para priorizar aún más entre estos montones y recursos, los 16 bits más bajos de la prioridad se establecen en el tamaño del montón o recurso dividido por 10 MB (saturando a 0xFFFF para montones extremadamente grandes). Esta priorización adicional favorece grandes montones y recursos.

El cubo de prioridad baja contiene todos los demás montones y recursos, a los que se les asigna un valor de prioridad de D3D12_RESIDENCY_PRIORITY_NORMAL. No se intenta realizar ninguna priorización adicional entre estos montones y recursos.

Programación de la administración de residencia

Es posible que las aplicaciones sencillas puedan obtener simplemente creando recursos confirmados hasta que se produzcan errores de memoria insuficiente. Tras un error, la aplicación puede destruir otros recursos confirmados o objetos de API para permitir que las creaciones de recursos se realicen correctamente. Sin embargo, incluso se recomienda encarecidamente que las aplicaciones simples watch para cambios de presupuesto negativos y destruir objetos de API sin usar aproximadamente una vez un marco.

La complejidad de un diseño de administración de residencia aumentará al intentar optimizar las arquitecturas de adaptador o incorporar prioridades de residencia. El presupuesto discreto y la administración de dos grupos de memoria discreta serán más complejos que administrar solo uno, y asignar prioridades fijas a gran escala puede convertirse en una carga de mantenimiento si evolucionan los patrones de uso. La desbordamiento de texturas en la memoria del sistema agrega más complejidad, ya que el recurso incorrecto en la memoria del sistema puede afectar gravemente a la velocidad de fotogramas. Además, no hay ninguna funcionalidad sencilla para ayudar a identificar los recursos que se beneficiarían de un mayor ancho de banda de GPU o tolerar un menor ancho de banda de GPU.

Los diseños aún más complicados consultarán las características del adaptador actual. Esta información está disponible en D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIER y D3D12_RESOURCE_HEAP_TIER.

Es probable que varias partes de una aplicación aparezcan usando diferentes técnicas. Por ejemplo, algunas texturas grandes y rara vez las rutas de acceso de código con ejercicio pueden usar recursos confirmados, mientras que muchas texturas se pueden designar con una propiedad de streaming y usar una técnica general de recursos colocados.

ID3D12Heap

Administración de memoria