Condividi tramite


Uso di una firma radice

La firma radice è la definizione di una raccolta arbitrariamente disposta di tabelle del descrittore (incluso il relativo layout), costanti radice e descrittori radice. Ogni voce ha un costo per un limite massimo, in modo che l'applicazione possa bilanciare il numero di ogni tipo di voce che conterrà la firma radice.

La firma radice è un oggetto che può essere creato tramite specifica manuale nell'API. Tutti gli shader in un PSO devono essere compatibili con il layout radice specificato con psoo, altrimenti i singoli shader devono includere layout radice incorporati che corrispondono tra loro; in caso contrario, la creazione pso avrà esito negativo. Una proprietà della firma radice è che gli shader non devono conoscerlo quando vengono creati, anche se le firme radice possono essere create direttamente negli shader, se necessario. Gli asset shader esistenti non richiedono alcuna modifica compatibile con le firme radice. Il modello shader 5.1 è stato introdotto per offrire una maggiore flessibilità (indicizzazione dinamica dei descrittori dall'interno degli shader) e può essere adottato in modo incrementale a partire dagli asset shader esistenti in base alle esigenze.

Semantica elenco comandi

All'inizio di un elenco di comandi, la firma radice non è definita. Gli shader grafici hanno una firma radice separata dallo shader di calcolo, ognuna assegnata in modo indipendente in un elenco di comandi. Anche la firma radice impostata su un elenco di comandi o un bundle deve corrispondere al PSO attualmente impostato in Draw/Dispatch; in caso contrario, il comportamento non è definito. La firma radice temporanea non corrisponde prima che Draw/Dispatch funzioni correttamente, ad esempio l'impostazione di un PSO incompatibile prima di passare a una firma radice compatibile (purché siano compatibili con il momento in cui viene chiamato Draw/Dispatch). L'impostazione di un PSO non modifica la firma radice. L'applicazione deve chiamare un'API dedicata per impostare la firma radice.

Dopo aver impostato una firma radice in un elenco di comandi, il layout definisce il set di associazioni che l'applicazione deve fornire e quali PSO possono essere usati (compilati con lo stesso layout) per le chiamate di disegno/dispatch successive. Ad esempio, una firma radice può essere definita dall'applicazione in modo da avere le voci seguenti. Ogni voce viene definita "slot".

  • [0] Descrittore CBV inline (descrittori radice)
  • [1] Tabella del descrittore contenente 2 SRV, 1 CBV e 1 UAV
  • [2] Tabella del descrittore contenente 1 campionatore
  • [3] Raccolta di costanti radice a 4x32 bit
  • [4] Tabella del descrittore contenente un numero non specificato di SRV

In questo caso, prima di poter eseguire un'operazione Draw/Dispatch, l'applicazione deve impostare l'associazione appropriata su ognuno degli slot [0..4] definiti dall'applicazione con la firma radice corrente. Ad esempio, nello slot [1], è necessario associare una tabella del descrittore, ovvero un'area contigua in un heap descrittore che contiene (o conterrà all'esecuzione) 2 VV, 1 CBV e 1 UAV. Analogamente, le tabelle dei descrittori devono essere impostate in corrispondenza degli slot [2] e [4].

L'applicazione può modificare parte delle associazioni di firma radice alla volta (il resto rimane invariato). Ad esempio, se l'unica cosa che deve cambiare tra le estrazioni è una delle costanti nello slot [2], ovvero tutte le applicazioni devono essere riassociate. Come illustrato in precedenza, il driver o l'hardware aggiorna tutti lo stato di associazione della firma radice perché viene modificato automaticamente. Se una firma radice viene modificata in un elenco di comandi, tutte le associazioni di firma radice precedenti diventano non aggiornate e tutte le nuove associazioni previste devono essere impostate prima di Draw/Dispatch; in caso contrario, il comportamento non è definito. Se la firma radice è impostata in modo ridondante sullo stesso set, le associazioni di firma radice esistenti non diventano obsoleti.

Semantica bundle

I bundle ereditano le associazioni di firma radice dell'elenco di comandi (le associazioni ai vari slot nell'esempio dell'elenco di comandi precedente). Se un bundle deve modificare alcune delle associazioni di firma radice ereditate, deve innanzitutto impostare la firma radice come l'elenco dei comandi chiamante (le associazioni ereditate non diventano obsoleti). Se il bundle imposta la firma radice in modo che sia diversa dall'elenco dei comandi chiamante, ha lo stesso effetto della modifica della firma radice nell'elenco di comandi descritto in precedenza: tutte le associazioni di firma radice precedenti sono non aggiornate e le associazioni previste devono essere impostate prima di Draw/Dispatch; in caso contrario, il comportamento non è definito. Se non è necessario modificare associazioni di firma radice, non è necessario impostare la firma radice.

Il codice seguente illustra un flusso di chiamate di esempio in un bundle.

// 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(...);
...

In uscita da un bundle, le modifiche al layout radice e/o l'associazione apportate da un bundle vengono ereditate nell'elenco dei comandi chiamante al termine dell'esecuzione di un bundle.

Per altre informazioni sull'ereditarietà, vedere la sezione Relativa all'ereditarietà dello stato della pipeline grafica di Gestione dello stato della pipeline grafica in Direct3D 12.

Firme radice