Compartir a través de

Residencia

  • Artículo

Se considera que un objeto es residente cuando la GPU puede acceder a él.

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 física discreta. En D3D12, la mayoría de los objetos de API encapsulan cierta cantidad de memoria accesible para GPU. Esa memoria accesible para GPU se hace 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 despiertan y duermen; y fluctúan drásticamente cuando el usuario cambia 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 se mantiene 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 deIDXGIAdapter3proporciona 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 ellas. Idealmente, la configuración de gráficos "baja" especificada por el usuario, o algo incluso menor, es el valor adecuado para dicha reserva. Establecer una reserva nunca dará a una aplicación un presupuesto más alto de lo 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 grandes. 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 memoria accesible para GPU, se espera que los montones & recursos sean la forma más significativa 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.

  • Los montones no se pueden realizar parcialmente residentes, pero existen soluciones alternativas con recursos reservados.
  • Los montones se deben presupuestar 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 último recurso extremo. Las aplicaciones no deben basarse 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 del adaptador. En adaptadores en los que el campo deD3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT maxGPUVirtualAddressBitsPerProcess está cerca del tamaño del presupuesto, 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 que el subproceso represente. En D3D12, varios subprocesos pueden llamar de forma segura a crear rutinas 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 tener acceso directamente. 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 un administrador de residencia basado en páginas totalmente general aún no es factible.

Prioridades de residencia

Windows 10 Creators Update permite a los desarrolladores influir en qué montón y recursos se preferirán permanecer residentes cuando la presión de memoria requiera que algunos de sus recursos se degradan. 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 crear la restablecimiento y los recursos en mosaico.

Aplicar estas prioridades debe ser más fácil que administrar dos presupuestos de memoria dinámica, degradar y promover manualmente los recursos, ya que las aplicaciones ya pueden hacerlo. Por lo tanto, el diseño de la API de prioridad de residencia se define de forma evidente 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 las 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 este enfoque lo aprovechen las aplicaciones portados desde API de gráficos, como Direct3D 11 o OpenGL, que es significativamente diferente al de Direct3D 12.
  • Invalide casi todas las prioridades del montón con el propio esquema de bucketización 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 interrumpir 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 es clasificar los montones en dos cubos, lo que favorece (dar prioridad más alta a) los montones que se supone que la GPU escribe con frecuencia en montones que no.

El cubo de alta prioridad 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 desordenadas (UAV). Estos son valores de prioridad asignados 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 (saturación en 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 priorizar aún más entre estos montones y recursos.

Administración de residencias de programación

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 adicionales se realicen correctamente. Sin embargo, incluso se recomienda encarecidamente que las aplicaciones sencillas observen cambios de presupuesto negativos y destruyan 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_TIERy D3D12_RESOURCE_HEAP_TIER.

Es probable que varias partes de una aplicación terminen usando diferentes técnicas. Por ejemplo, algunas texturas grandes y rara vez las rutas de acceso de código realizadas 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 de