Diferencias en el modelo de enlace de Direct3D 11
Una de las principales decisiones de diseño detrás del enlace de DirectX12 es separarla de otras tareas de administración. Esto coloca algunos requisitos en la aplicación para administrar ciertos posibles peligros.
La principal ventaja del modelo de enlace D3D12 es que permite a las aplicaciones cambiar los enlaces de textura con frecuencia, sin un enorme costo de rendimiento de CPU. Otras ventajas son que los sombreadores tienen acceso a un gran número de recursos, los sombreadores no necesitan saber con antelación cuántos recursos se enlazarán y que se puede usar un modelo de enlace de recursos unificado independientemente del hardware o el flujo de contenido de las aplicaciones.
Para mejorar el rendimiento, el modelo de enlace no requiere que el sistema realice un seguimiento de los enlaces que una aplicación ha solicitado que use la GPU y hay una integración limpia entre las listas de comandos de enlace y multiproceso.
En las secciones siguientes se enumeran algunos de los cambios en el modelo de enlace de recursos desde D3D11.
- Administración de residencia de memoria separada del enlace
- Administración de duración de objetos separados del enlace
- Seguimiento de estado de recursos del controlador separado del enlace
- Sincronización de memoria asignada por GPU de CPU separada del enlace
- Temas relacionados
Administración de residencia de memoria separada del enlace
Las aplicaciones tienen un control explícito sobre qué superficies deben estar disponibles para que la GPU la use directamente (denominada "residente"). Por el contrario, pueden aplicar otros estados en recursos, como convertirlos explícitamente en no residentes, o permitir que el sistema operativo elija para determinadas clases de aplicaciones que requieren una superficie de memoria mínima. El punto importante aquí es que la administración de la aplicación de lo que es residente está completamente desacoplada de la forma en que proporciona acceso a los recursos a los sombreadores.
La desacoplamiento de la administración de residencias del mecanismo para proporcionar a los sombreadores acceso a los recursos reduce el costo del sistema o hardware para la representación, ya que el sistema operativo no tiene que inspeccionar constantemente el estado de enlace local para saber qué hacer residente. Además, los sombreadores ya no tienen que saber a qué superficies exactas pueden necesitar hacer referencia, siempre y cuando todo el conjunto de recursos posiblemente accesibles se haya hecho residente con antelación.
Administración de duración de objetos separados del enlace
A diferencia de las API anteriores, el sistema ya no realiza un seguimiento de los enlaces de recursos a la canalización. Esto se usa para permitir que el sistema mantenga activos los recursos que la aplicación ha publicado porque todavía se hace referencia a ellos por un trabajo pendiente de GPU.
Antes de liberar cualquier recurso, como una textura, las aplicaciones ahora deben asegurarse de que la GPU se ha completado haciendo referencia a él. Esto significa que, para que una aplicación pueda liberar de forma segura un recurso, la GPU debe haber completado la ejecución de la lista de comandos que hace referencia al recurso.
Seguimiento de estado de recursos del controlador separado del enlace
El sistema ya no inspecciona los enlaces de recursos para comprender cuándo se han producido transiciones de recursos que requieren trabajo adicional de controlador o GPU. Un ejemplo común para muchas GPU y controladores es tener que saber cuándo una superficie pasa de usarse como una vista de destino de representación (RTV) a la vista de recursos del sombreador (SRV). Las propias aplicaciones deben identificar ahora si cualquier transición de recursos que el sistema pueda preocuparse por se está produciendo a través de API dedicadas.
Sincronización de memoria asignada por GPU de CPU separada del enlace
El sistema ya no inspecciona los enlaces de recursos para comprender si la representación debe retrasarse porque depende de un recurso que se haya asignado para el acceso a la CPU, pero que aún no se haya asignado. Las aplicaciones ahora tienen la responsabilidad de sincronizar el acceso a memoria de CPU y GPU. Para ayudar con esto, el sistema proporciona mecanismos para que la aplicación solicite la suspensión de un subproceso de CPU hasta que se complete el trabajo. El sondeo también se puede realizar, pero puede ser menos eficaz.
Temas relacionados