Uso de una firma raíz
La firma raíz es la definición de una colección organizada arbitrariamente de tablas descriptores (incluido su diseño), constantes raíz y descriptores raíz. Cada entrada tiene un costo hacia un límite máximo, por lo que la aplicación puede equilibrar el saldo entre el número de cada tipo de entrada que contendrá la firma raíz.
La firma raíz es un objeto que se puede crear mediante la especificación manual en la API. Todos los sombreadores de un ARCHIVO deben ser compatibles con el diseño raíz especificado con el ARCHIVO DE, o bien los sombreadores individuales deben incluir diseños raíz incrustados que coincidan entre sí; de lo contrario, se producirá un error en la creación de LA SESIÓN. Una propiedad de la firma raíz es que los sombreadores no tienen que saberlo cuando se crean, aunque las firmas raíz también se pueden crear directamente en sombreadores si lo desea. Los recursos de sombreador existentes no requieren que los cambios sean compatibles con las firmas raíz. El modelo de sombreador 5.1 se presenta para proporcionar cierta flexibilidad adicional (indexación dinámica de descriptores desde los sombreadores) y se puede adoptar incrementalmente a partir de los recursos de sombreador existentes según sea necesario.
Semántica de lista de comandos
Al principio de una lista de comandos, la firma raíz no está definida. Los sombreadores de gráficos tienen una firma raíz independiente del sombreador de proceso, cada una asignada de forma independiente en una lista de comandos. La firma raíz establecida en una lista o agrupación de comandos también debe coincidir con el CONJUNTO ACTUALMENTE ESTABLECIDO EN DRAW/Dispatch; de lo contrario, el comportamiento no está definido. Los errores de coincidencia de las firmas raíz transitorias antes de Draw/Dispatch son correctos, como establecer un ARCHIVO incompatible antes de cambiar a una firma raíz compatible (siempre y cuando se llame a draw/Dispatch). Si se establece UN ARCHIVO, no se cambia la firma raíz. La aplicación debe llamar a una API dedicada para establecer la firma raíz.
Una vez que se ha establecido una firma raíz en una lista de comandos, el diseño define el conjunto de enlaces que se espera que proporcione la aplicación y qué SPO se pueden usar (los compilados con el mismo diseño) para las siguientes llamadas a draw/dispatch. Por ejemplo, la aplicación podría definir una firma raíz para que tenga las siguientes entradas. Cada entrada se conoce como "ranura".
- [0] Un descriptor CBV insertado (descriptores raíz)
- [1] Tabla de descriptores que contiene 2 SRV, 1 CBV y 1 UAV
- [2] Tabla descriptor que contiene 1 sampler
- [3] Colección de constantes raíz de 4 x 32 bits
- [4] Una tabla descriptor que contiene un número no especificado de SRV
En este caso, antes de poder emitir un Draw/Dispatch, se espera que la aplicación establezca el enlace adecuado en cada una de las ranuras [0..4] que la aplicación definió con su firma raíz actual. Por ejemplo, en la ranura [1], se debe enlazar una tabla de descriptores, que es una región contigua en un montón de descriptores que contiene (o contendrá en ejecución) 2 SRV, 1 CBV y 1 UAV. De forma similar, las tablas descriptores deben establecerse en las ranuras [2] y [4].
La aplicación puede cambiar parte de los enlaces de firma raíz a la vez (el resto permanece sin cambios). Por ejemplo, si lo único que necesita cambiar entre draws es una de las constantes en la ranura [2], es decir, toda la aplicación debe volver a enlazarse. Como se ha explicado anteriormente, el controlador o el hardware versiones de todo el estado de enlace de firma raíz, ya que se modifica automáticamente. Si se cambia una firma raíz en una lista de comandos, todos los enlaces de firma raíz anteriores se vuelven obsoletos y todos los enlaces recién esperados deben establecerse antes de Draw/Dispatch; de lo contrario, el comportamiento no está definido. Si la firma raíz se establece con redundancia en el mismo conjunto actualmente, los enlaces de firma raíz existentes no se vuelven obsoletos.
Semántica de agrupación
Los conjuntos heredan los enlaces de firma raíz de la lista de comandos (los enlaces a las distintas ranuras del ejemplo lista de comandos anterior). Si una agrupación necesita cambiar algunos de los enlaces de firma raíz heredados, primero debe establecer la firma raíz para que sea la misma que la lista de comandos que realiza la llamada (los enlaces heredados no se vuelven obsoletos). Si la agrupación establece que la firma raíz sea diferente de la lista de comandos que llama, que tiene el mismo efecto que cambiar la firma raíz en la lista de comandos descrita anteriormente: todos los enlaces de firma raíz anteriores son obsoletos y los enlaces recién esperados deben establecerse antes de Draw/Dispatch; de lo contrario, el comportamiento no está definido. Si una agrupación no necesita cambiar ningún enlace de firma raíz, no es necesario establecer la firma raíz.
En el código siguiente se muestra un flujo de llamadas de ejemplo a una agrupación.
// Command List
...
pCmdList->SetGraphicsRootSignature(pRootSig); // new parameter space
MyEngine_SetTextures(); // bundle inherits descriptor table setting
MyEngine_SetAnimationFactor(fTime); // bundle inherits root constant
pCmdList->ExecuteBundle(...);
...
// Bundle
pBundle->SetGraphicsRootSignature(pRootSig); // same as caller, in order to inherits bindings
pBundle->SetPipelineState(pPS);
pBundle->SetGraphicsRoot32BitConstant(drawConstantsSlot,0,drawIDOffset);
pBundle->Draw(...); // using inherited textures / animation factor
pBundle->SetGraphicsRoot32BitConstant(drawConstantsSlot,1,drawIDOffset);
pBundle->Draw(...);
...
Al salir de una agrupación, los cambios de diseño raíz o los cambios de enlace que realiza una agrupación se heredan de nuevo en la lista de comandos que realiza la llamada cuando una agrupación termina de ejecutarse.
Para obtener más información sobre la herencia, consulte la sección Herencia de estado de canalización de gráficos de Administración del estado de canalización de gráficos en Direct3D 12.
Temas relacionados