2013-04-09 13 views
5

tI sto lottando per comprendere i buffer costanti in DirectX. Ho visto due sintassiCome utilizzare i buffer costanti dello shader?

float4 myVar; 

dichiarati in alto a livello di file shader e

cbuffer myBuffer 
{ 
    float4 myVar; 
} 

come spiegato a http://msdn.microsoft.com/en-gb/library/windows/desktop/bb509581(v=vs.85).aspx

Capisco che i buffer costanti devono essere assegnati agli slot (zero basato su indici) e può essere impostato in codice.

I due framework che ho visto (SlimDX vs SharpDX) sembrano utilizzare diverse convenzioni per impostarli - SlimDX per nome stringa (tramite riflessione dello shader?) E SharpDX per numero di slot - sebbene non sia chiaro dove il numero di slot è ottenuto da?

Qualcuno può far luce sulla differenza tra le due sintassi, se sono effettivamente diverse, come i numeri di slot sono assegnati alle dichiarazioni nel file .fx e come i numeri di slot sono condivisi tra gli shader?

Qualsiasi aiuto apprezzato

risposta

10

Sia SharpDX che SlimDX utilizzano la stessa convenzione quando si utilizza l'API Direct3D10/Direct3D11 raw (tramite Direct3D10.Device.XXX.SetConstantBuffers e Direct3D11.DeviceContext.XXX.SetConstantBuffers).

Come indicato nel collegamento dalla documentazione MSDN, sezione "Buffer di costante di default", viene spiegato che la variabile non definita all'interno di un Buffer costante verrà terminata in un Global Constant Buffer predefinito denominato "$ Global".

D'altro canto, il framework di effetti legacy (che interagisce con RAW Direct3D10 + API) fornisce l'accesso alla singola variabile tramite il loro nome. Internamente utilizzano ShaderReflection per interrogare il contenuto di Constant Buffer e gestire automaticamente allocare/aggiornare/caricare questi buffer costanti. Alla fine questo è il buffer costante che verrà caricato nella GPU, non le singole variabili (che non esistono al di fuori del buffer costante). Il framework di effetti legacy gestisce dinamicamente lo slot per associare il buffer costante interrogando lo slot di binding usando ShaderReflection.

I numeri di slot sono assegnati dal compilatore in fase di compilazione. Se non si specifica esplicitamente un registro (vedere registro per cbuffer nella documentazione MSDN), il compilatore influirà sul primo slot disponibile per il primo cbuffer utilizzato. Non vi è alcuna garanzia che il compilatore influenzi lo stesso slot tra shader per gli stessi buffer costanti, a meno che non si imposti esplicitamente il registro.

+0

grazie - un follow up se va bene - tu dici qui che il framework Effect è legacy - vuol dire che anche gli effetti 11 dovrebbero essere evitati? Non riesco a vedere questo menzionato su http://msdn.microsoft.com/en-us/library/windows/desktop/ff476136(v=vs.85).aspx sebbene http://blogs.msdn.com/b /chuckw/archive/2012/10/24/effects-for-direct3d-11-update.aspx cita che viene fornito principalmente per facilitare il porting da Effects 10. La raccomandazione è di saltare del tutto il suo uso? – AnonDev

+2

Effetti11/Effetti/I file FX sono obsoleti e non vengono più gestiti da Microsoft (ecco perché l'intero Effects11 è accessibile solo dal vecchio SDK di DirectX di giugno 2010 o da un post di un blog). Quindi, non lo miglioreranno più per supportare le prossime funzionalità di Direct3D. È anche impossibile utilizzarlo dalle applicazioni RT di Windows. – xoofx

0

La documentazione si fa riferimento è per il D3D shader model pura api. Dovrai consultare ogni singolo middleware (SlimDX o SharpDX) per capire la corrispondenza tra la loro sintassi e la mappatura sottostante.

Direi che qualsiasi distribuzione di terze parti è completamente libera di definire la propria sintassi (e potrebbe essere implementata in qualsiasi modo eccessivamente complesso), ma è una cosa che devi accettare. Dovresti consultare la documentazione corrispondente di ciascun fornitore di terze parti per comprendere la mappatura, in quanto i dettagli possono anche variare da versione a versione. Se il codice sorgente è disponibile, puoi ispezionarlo per capire da solo la mappatura. E data la natura "black-box" di alcuni framework, ci si potrebbe aspettare che accettino semplicemente la documenation del framework - nel qual caso, fare riferimento alla documentazione della libreria canonica/base sarebbe un errore o una perdita di astrazione.

L'ultima domanda è: perché ti interessa l'implementazione/mappatura? L'intero punto di queste librerie è di astrarre i dettagli in modo conveniente. Personalmente, posso capire perché questo potrebbe essere frustrante (specialmente se si ricorre alla documentazione canonica invece della piattaforma per qualsiasi motivo), ma il costo relativo che si paga è una conseguenza/compromesso di scegliere una tale piattaforma invece di utilizzare il core biblioteca direttamente.

+0

grazie, non credo che estratto dal modello hardware buffer costanti hanno slot. La domanda due sintassi e how-slots-numbered è indipendente dal wrapper, penso? – AnonDev

+0

sì, sembra proprio che la tua domanda sollevi in ​​realtà la questione delle librerie core della libreria vs wrapper. Ci sono un sacco di problemi comuni che si verificano a seguito del prelievo di una libreria wrapper, che non sono necessariamente legati o unici al dominio del problema. Se aiuta, questa è la direzione dalla quale mi sto avvicinando. Il vero problema è che i framework cui si fa riferimento non hanno una documentazione adeguata? –

+0

Non penso che sia - sono entrambi wrapper sottili intorno a DirectX - il concetto di buffer slot è un concetto di DirectX e non un concetto di libreria wrapper. Credo che questo sia un problema di documentazione (o non trovo la documentazione). – AnonDev

1

La prima sintassi:

float4 myVar; 

è la sintassi effetto di Microsoft, dove, come il secondo è HLSL dritto. La sintassi degli effetti semplifica un po 'le cose allocando automaticamente i buffer costanti, ma ciò ha un costo di flessibilità.

Uso SharpDX è necessario assegnare un buffer costante slot 1 in questo modo:

cbuffer myBuffer: register(b1) 
{ 
    float4 myVar; 
}