Estrategias de administración de la memoria
Un administrador de memoria para Direct3D 12 podría complicarse rápidamente con todos los distintos niveles de soporte técnico, para adaptadores de UMA o discretos (no UMA) y con una considerable variedad de diferencias de arquitectura entre adaptadores de GPU.
La estrategia recomendada para la administración de memoria de Direct3D 12, descrita en esta sección, es "clasificar, presupuestar y transmitir".
Tipos de recursos
El concepto básico de un "recurso confirmado" (la creación de espacios de direcciones virtuales y físicos inicializados en memoria física administrada) ha existido desde Direct3D 9, aunque el direccionamiento virtual (VA) y el direccionamiento físico se pueden separar en Direct3D 12 para permitir que la aplicación administre cuidadosamente la memoria física.
Además de los recursos confirmados, la construcción del montón de Direct3D 12 permite otros dos tipos de recursos: "colocado" y "reservado". En Direct3D 11, un recurso "reservado" se conocía como "recurso en mosaico".
Los recursos reservados difieren de los recursos colocados en que los recursos reservados tienen su propio espacio de direcciones virtuales de GPU único. Esto permite una asignación grande de espacio de VA por adelantado y, a continuación, permite la asignación de páginas de VA a determinadas secciones del montón más adelante y la aplicación vuelve a configurar la disposición sobre la marcha. El espacio va es contiguo y se puede asignar dispersamente.
El recurso reservado se puede hacer para hacer referencia a regiones del montón con llamadas API como UpdateTileMappings y que la aplicación puede realizar residentes actualizando las tablas de páginas sobre la marcha. Cuando un intervalo de VA se asigna a NULL o a un montón no residente, esa parte del recurso se considera no residente. Cuando un intervalo de VA se asigna a un montón residente, esa parte del recurso se considera residente. Los montones residen en la creación.
Los recursos colocados son un diseño mucho más sencillo, siendo simplemente un puntero a una determinada región de un montón (por ejemplo, una región de 1 Mb para una textura en un montón de 5 Mb). Las barreras de alias permiten el uso de recursos colocados superpuestos (consulte CreatePlacedResource y ResourceBarrier).
Los recursos reservados no están disponibles en todo el hardware de Direct3D 12 y los recursos colocados son una reserva razonable, aunque los recursos colocados deben ser contiguos y no pueden residir parcialmente.
Presupuesto de memoria
En Direct3D 12, al asignar un montón, se crea el aspecto de memoria física de un recurso confirmado. La opción de segmento de memoria más explícita está disponible en Direct3D 12 (eligiendo entre el vídeo y la memoria del sistema). Los adaptadores de UMA solo tienen un solo segmento de memoria, memoria del sistema.
Las GPU no admiten errores de página, por lo que los desarrolladores deben estar conscientes de que no se confirman por encima, especialmente en sistemas que dicen con solo 1 Gb de memoria del sistema. Si una aplicación supera la confirmación, el sistema operativo usa una programación general de procesos por su demanda en la memoria física. El programador inmovilizará los procesos en primer plano y básicamente paginará parte de él, con el fin de paginar en un proceso en segundo plano que quiera ejecutarse. La memoria física disponible puede variar considerablemente en función de lo que hace el usuario en segundo plano (por ejemplo, ejecutar un explorador o ver un vídeo).
La API para el presupuesto de memoria es QueryVideoMemoryInfo. En el caso de los adaptadores discretos "local" es la memoria de vídeo, "no local" es la memoria del sistema. En el caso de los adaptadores de UMA que no son locales, siempre es cero. Una pregunta de diseño es si el motor administrará ambos presupuestos o solo el presupuesto local. Administrar solo el presupuesto local es más sencillo, pero tiene algunas advertencias; por ejemplo, supongamos que hay un presupuesto local máximo de 1 Gb, entonces todos los montones provendrán de ese 1 Gb en un sistema UMA y no hay desbordamiento en la memoria del sistema (claramente, ya que no hay ninguno).
Puesto que la memoria administrada de Direct3D11 para las aplicaciones, los recursos no utilizados se paginarían básicamente.
Elija las dimensiones de recursos más adecuadas. Tenga en cuenta si el tamaño de un recurso es adecuado para la situación en la que la aplicación se está ejecutando realmente. Algunos usuarios pueden ejecutar la aplicación en una ventana o con una resolución de pantalla de 800 x 600.
Estrategia de clasificación
Para administrar los recursos de forma eficaz en escenarios enlazados a memoria, considere la posibilidad de clasificar los recursos en lo siguiente:
| clasificación | Ejemplos | Objetos y características de API | Notas de administración |
|---|---|---|---|
| Crítico | Interfaz de usuario del juego | Asignador de comandos, colas de comandos, montones de consultas, recursos y montones de recursos. | Estos elementos deben estar en memoria no paginable o siempre confirmada. |
| Escalado o opcional | Modelos y texturas específicos de nivel, cadenas de intercambio, cajas sky, modelos de personajes de jugador de primera persona | Recursos y montones. Los recursos confirmados, pero también los recursos reservados y colocados pueden funcionar también. | Integre el presupuesto de residencia de memoria en los algoritmos de representación. Elija el nivel adecuado de detalle disponible y vuelva a evaluarlo menos de una vez por fotograma. Las técnicas incluyen el uso de recursos de tamaño variable y el escalado de cadenas de intercambio. |
| Recursos reutilizados | Búferes de sombras, recursos de representación diferidos, recursos posteriores al procesamiento, memorias caché de datos de iluminación | Recursos y montones. Superposición de recursos colocados en montones y barreras de alias. | Reutilice recursos grandes o regiones de montón dentro de un marco para reducir los requisitos de todo el fotograma. Use la técnica de reutilización de memoria dentro del marco. En Direct3D 11, las aplicaciones solo podían reutilizar recursos con el mismo tipo y dimensiones potencialmente grandes. Los montones de Direct3D 12 permiten que los recursos superpuestos sean mucho más sencillos y más reutilizados. |
| Recursos de streaming | Terreno, texturas de mundo abierto y geometría | Recursos y montones. Creación de subprocesos libres, subprocesos de CPU en segundo plano y listas y colas de comandos de copia en segundo plano. | La residencia parcial, normalmente basada en la visibilidad (mediante el frustum de vista o la evaluación basada en distancia) y volver a evaluar la residencia necesita cada fotograma. La técnica de usar una administración parcial de residencia por icono y la reutilización entre fotogramas está disponible cuando el adaptador de GPU admite recursos reservados dentro de montones. Con la técnica de usar la reutilización de memoria entre fotogramas, se puede lograr la residencia parcial de subrecursos, pero es menos óptima. Los recursos colocados con montones deben permitir un reciclaje más rápido, pero los recursos confirmados se pueden usar como reserva. |
Cuantos más aplicaciones se insteten a los recursos de streaming para la mayor parte del trabajo, más aprovecharán los recursos colocados y reservados, lo que maximizará el uso de memoria entre estas cuatro clasificaciones. Cuantos más aplicaciones transmitan, más presupuestan y priorizan el ancho de banda.
Normalmente, con los motores gráficos direct3D 12 necesitan respetar un presupuesto más diverso y dinámico, y hacerlo más estrictamente de lo que hicieron en el pasado. Las mejores aplicaciones localizarán las cuatro categorías en el presupuesto dado al proceso, escalando el juego desde la aplicación móvil en segundo plano hasta presupuestos discretos de pantalla completa. Sin embargo, es probable que muchas aplicaciones tengan dificultades empezando por demasiados tipos de categoría críticos de recursos. Los recursos de Direct3D 11 habilitados para crearse de forma anónima y ocupar el estado crítico sin afectar al rendimiento. Sin embargo, para Direct3D 12, los desarrolladores deben buscar diligentemente recursos creados aleatoriamente en todo su motor y middleware y volver a asignarlos a una de las otras categorías.
Otras áreas problemáticas son componentes de middleware, controles de usuario y streaming dentro de fotogramas. Es posible que los componentes de middleware no se expongan a un presupuesto ni tengan que trabajar estrechamente juntos. Los componentes de middleware probablemente podrían exponer características como técnicas de representación; y la aplicación podría basarse en la exposición del middleware y la configuración del motor. Los desarrolladores podrían confiar en Direct3D 11 para realizar la paginación y lograr la velocidad de fotogramas correcta. En algunos casos, las aplicaciones de Direct3D 11 pueden haber estado paginando el contenido de los recursos dentro y fuera de cada fotograma; y dio lugar a velocidades de fotograma aceptables para el usuario. La mayoría de los motores solo transmiten datos de recursos como una actividad en segundo plano, donde no tiene ninguna reserva correcta a la transmisión dentro de fotogramas de alta prioridad. Pedir a los motores que implementen que dañarán algunas de las ganancias de sobrecarga de CPU que buscan al pasar a Direct3D 12. Los desarrolladores de motores podrían considerar la posibilidad de analizar sus fotogramas en fases para proporcionar más oportunidades para los recursos que se pueden reutilizar; y es probable que trabajen con proveedores de middleware para admitir recursos colocados y montones para volver a usar la memoria dentro de fotogramas.