Considerazioni da Direct3D 9 a Direct3D 10 (Direct3D 10)
La pagina seguente fornisce una struttura di base delle differenze principali tra Direct3D 9 e Direct3D 10. La struttura seguente fornisce alcune informazioni dettagliate per aiutare gli sviluppatori con l'esperienza Direct3D 9 per esplorare e correlare a Direct3D 10.
Anche se le informazioni in questo argomento confrontano Direct3D 9 con Direct3D 10, perché Direct3D 11 si basa sui miglioramenti apportati in Direct3D 10 e 10.1, sono necessarie anche queste informazioni per eseguire la migrazione da Direct3D 9 a Direct3D 11. Per informazioni sul passaggio da Direct3D 10 a Direct3D 11, vedi Migrazione a Direct3D 11.
- Panoramica dei principali cambiamenti strutturali in Direct3D 10
- Astrazioni/separazione del motore
- Trucchi per la risoluzione rapida dei problemi di compilazione delle applicazioni
- Guida all'API Direct3D 10
- Creazione di risorse
- Visualizzazioni
- Accesso a risorse statiche e dinamiche
- Effetti direct3D 10
- HLSL senza effetti
- Compilazione shader
- Creazione di risorse shader
- Interfaccia del livello reflection shader
- Layout dell'assembler di input - Vertex Shader/Input Stream Linkage
- Impatto della rimozione del codice non recapitabili dello shader
- Esempio di struttura di input vertex shader
- Creazione di oggetti di stato
- Conversione di trame
- Porting shader
- Differenze aggiuntive per Direct3D 10 da controllare
- Differenze aggiuntive di Direct3D 10.1
- Argomenti correlati
Panoramica dei principali cambiamenti strutturali in Direct3D 10
Il processo di rendering con il dispositivo Direct3D 10 è strutturalmente simile a Direct3D 9.
- Impostare un'origine del flusso di vertici
- Impostare il layout di input in Direct3D 10 (impostare la dichiarazione del flusso di vertici in Direct3D 9)
- Dichiarare la topologia primitiva
- Impostare trame
- Impostare gli oggetti di stato
- Impostare shader
- Draw
La chiamata Draw collega le operazioni. L'ordinamento delle chiamate prima della chiamata Draw è arbitrario. Le principali differenze nella progettazione api Direct3D 10 sono le seguenti:
- Rimozione della funzione fissa
- Rimozione dei bit CAPS : è garantito il set di funzionalità di base di Direct3D 10
- Gestione più restrittiva di: accesso alle risorse, stato del dispositivo, costanti shader, collegamento dello shader (input e output agli shader) tra le fasi
- Le modifiche al nome del punto di ingresso dell'API riflettono l'uso della memoria GPU virtuale (Map() invece di Lock()).
- È possibile aggiungere un livello di debug al dispositivo in fase di creazione
- La topologia primitiva è ora uno stato esplicito (separato dalla chiamata Draw)
- Le costanti shader esplicite vengono ora archiviate in buffer costanti
- La creazione di shader viene eseguita interamente in HLSL. Il compilatore HLSL ora si trova nella DLL direct3D 10 primaria.
- Nuova fase programmabile: il geometry shader
- Rimozione di BeginScene()/EndScene()
- Funzionalità comuni di gestione degli adattatori e dello stato attivo 2D implementate in un nuovo componente: DXGI
Rimozione della funzione fissa
A volte è sorprendente che anche in un motore Direct3D 9 che sfrutta completamente la pipeline programmabile, rimane una serie di aree che dipendono dalla pipeline a funzione fissa (FF). Le aree più comuni sono in genere correlate al rendering allineato allo spazio dello schermo per l'interfaccia utente. Per questo motivo è probabile che sia necessario creare uno shader di emulazione FF o un set di shader che forniscono i comportamenti di sostituzione necessari.
Questa documentazione contiene un white paper contenente origini shader sostitutive per i comportamenti FF più comuni (vedere Esempio di EMU di funzioni fisse). Alcuni comportamenti pixel a funzione fissa, incluso il test alfa, sono stati spostati in shader.
Convalida dell'ora di creazione dell'oggetto dispositivo
La pipeline Direct3D 10 è stata riprogettata da zero in hardware e software con l'intenzione principale di ridurre il sovraccarico della CPU (in fase di disegno). Per ridurre i costi, a tutti i tipi di dati del dispositivo è stato assegnato un oggetto con metodi di creazione espliciti forniti dal dispositivo stesso. Ciò consente una convalida rigorosa dei dati in fase di creazione dell'oggetto anziché durante la chiamata Draw, come spesso avviene con Direct3D 9.
Astrazioni/separazione del motore
Le applicazioni, inclusi i giochi, che desiderano supportare sia Direct3D 9 che Direct3D 10 devono avere i livelli di rendering astratti dal resto della codebase. Esistono molti modi per ottenere questo risultato, ma la chiave per tutti è la progettazione del livello di astrazione per il dispositivo Direct3D di livello inferiore. Tutti i sistemi devono comunicare con l'hardware tramite il livello comune progettato per fornire risorse GPU e gestione dei tipi di basso livello.
Rimozione diretta delle dipendenze direct3D 9
Quando si esegue la conversione di codebase di grandi dimensioni, precedentemente testate, è importante ridurre al minimo la quantità di modifiche di codice a quelle assolutamente necessarie per mantenere i comportamenti testati in precedenza nel codice. Le procedure consigliate includono la documentazione chiara in cui gli elementi cambiano usando i commenti. Spesso è utile avere uno standard di commento per questo lavoro che consente di spostarsi rapidamente attraverso la codebase.
Di seguito è riportato un elenco di esempi di commenti a riga singola/blocco iniziale standard che possono essere usati per questo lavoro.
| Articolo | Descrizione |
|---|---|
| Direct3D 10 RIMOSSO |
Usare questa opzione in cui vengono rimosse righe/blocchi di codice |
| AGGIORNAMENTO DELLE ESIGENZE DI Direct3D 10 |
Consente di aggiungere note aggiuntive al commento NEED UPDATE che suggerisce il lavoro o la nuova API da usare per le visite successive al codice per la conversione del comportamento. È inoltre consigliabile usare un uso elevato di assert(false) in cui si verifica \\ Direct3D 10 NEEDS UPDATE per assicurarsi di non eseguire inconsapevolmente il codice errant |
| Direct3D 10 MODIFICATO |
Le aree in cui si sono verificate modifiche importanti devono essere mantenute per riferimento futuro, ma commentate |
| // Direct3D 10 END |
Qualificatore del blocco di codice finale |
Per più righe di origine è consigliabile usare anche i commenti /* */ di stile C, ma aggiungere i commenti di inizio/fine pertinenti in queste aree.
Trucchi per la risoluzione rapida dei problemi di compilazione delle applicazioni
- Override dei tipi Direct3D 9
- Risoluzione dei problemi di collegamento
- Simulazione di CAP del dispositivo
Override dei tipi Direct3D 9
Può essere utile inserire un file di intestazione di alto livello contenente definizioni di tipi/override per i tipi di base Direct3D 9 che non sono più supportati dalle intestazioni Direct3D 10. Ciò consente di ridurre al minimo la quantità di modifiche nel codice e nelle interfacce in cui è presente un mapping diretto da un tipo Direct3D 9 al tipo Direct3D 10 appena definito. Questo approccio è utile anche per mantenere insieme i comportamenti del codice in un unico file di origine. In questo caso, è consigliabile definire tipi indipendenti dalla versione o in genere denominati che descrivono costrutti comuni usati per il rendering, ma si estendono sia sulle API Direct3D 9 che su Direct3D 10. Ad esempio:
#if defined(D3D9)
typedef IDirect3DIndexBuffer9 IDirect3DIndexBuffer;
typedef IDirect3DVertexBuffer9 IDirect3DVertexBuffer;
#else //D3D10
typedef ID3D10Buffer IDirect3DIndexBuffer;
typedef ID3D10Buffer IDirect3DVertexBuffer
#endif
Altri esempi specifici di Direct3D 10 includono:
typedef ID3D10TextureCube IDirect3DCubeTexture;
typedef ID3D10Texture3D IDirect3DVolumeTexture;
typedef D3D10_VIEWPORT D3DVIEWPORT;
typedef ID3D10VertexShader IDirect3DVertexShader;
typedef ID3D10PixelShader IDirect3DPixelShader;
Risoluzione dei problemi di collegamento
È consigliabile sviluppare applicazioni Direct3D 10 e Windows Vista usando la versione più recente di Microsoft Visual Studio. Tuttavia, è possibile compilare un'applicazione Windows Vista che dipende da Direct3D 10 usando la versione precedente 2003 di Visual Studio. Direct3D 10 è un componente della piattaforma Windows Vista con dipendenze (come con l'SDK della piattaforma Server 2003 SP1) nella libreria seguente: BufferOverflowU.lib è necessario per risolvere eventuali problemi del linker di controllo buffer_security.
Simulazione di CAP del dispositivo
Molte applicazioni contengono aree di codice che dipendono dai dati CAPS del dispositivo disponibili. Risolvere questo problema eseguendo l'override dell'enumerazione del dispositivo e forzando i CAPS del dispositivo a valori sensibili. Pianificare nuovamente le aree in cui sono presenti dipendenze dai CAPS in un secondo momento per la rimozione completa dei CAPS, laddove possibile.
Guida all'API Direct3D 10
Questa sezione è incentrata sulle modifiche del comportamento causate dall'API Direct3D 10.
- Creazione di risorse
- Visualizzazioni
- Accesso a risorse statiche e dinamiche
- Effetti direct3D 10
- HLSL senza effetti
- Compilazione shader
- Creazione di risorse shader
- Interfaccia del livello reflection shader
- Layout dell'assembler di input - Vertex Shader/Input Stream Linkage
- Impatto della rimozione del codice non recapitabili dello shader
- Esempio di struttura di input vertex shader
- Creazione di oggetti di stato
Creazione di risorse
L'API Direct3D 10 ha progettato le risorse come tipi di buffer generici con flag di associazione specifici in base all'utilizzo pianificato. Questo punto di progettazione è stato scelto per facilitare l'accesso quasi universale delle risorse nella pipeline per scenari come il rendering in un buffer dei vertici, quindi disegnare immediatamente i risultati senza interrompere la CPU. L'esempio seguente illustra l'allocazione di vertex buffer e buffer di indice in cui è possibile notare che la descrizione della risorsa è diversa solo dai flag di associazione di risorse GPU.
L'API Direct3D 10 ha fornito metodi helper trama per creare in modo esplicito le risorse del tipo di trama, ma come si può immaginare, queste sono davvero funzioni helper.
- CreateTexture2D()
- CreateTextureCube()
- CreateTexture3D()
Quando la destinazione è Direct3D 10, è probabile che si voglia allocare più elementi durante il tempo di creazione delle risorse rispetto a quello usato con Direct3D 9. Questo diventerà più evidente con la creazione di buffer di destinazione di rendering e trame in cui è necessario creare anche una visualizzazione per accedere al buffer e impostare la risorsa nel dispositivo.
Esercitazione 1: Nozioni di base su Direct3D 10
Nota
Direct3D 10 e versioni successive di Direct3D estendono il formato di file DDS per supportare nuovi formati DXGI, matrici di trame e matrici mappa cubo. Per altre informazioni sull'estensione del formato di file DDS, vedere la Guida alla programmazione per DDS.
Visualizzazioni
Una visualizzazione è un'interfaccia tipizzata specificamente per i dati archiviati in un buffer di pixel. Una risorsa può avere diverse visualizzazioni allocate contemporaneamente e questa funzionalità è evidenziata nell'esempio Single Pass Render to Cubemap contenuto in questo SDK.
Pagina Guida per programmatori in Accesso alle risorse
Accesso a risorse statiche e dinamiche
Per ottenere prestazioni ottimali, le applicazioni devono partizionare l'uso dei dati in termini di natura statica e dinamica dei dati. Direct3D 10 è stato progettato per sfruttare questo approccio e, di conseguenza, le regole di accesso per le risorse sono state notevolmente rafforzate rispetto a Direct3D 9. Per le risorse statiche è consigliabile popolare la risorsa con i relativi dati durante la creazione. Se il motore è stato progettato per creare, bloccare, riempire, sbloccare il punto di progettazione direct3D 9, è possibile rinviare il popolamento in fase di creazione usando una risorsa di staging e il metodo UpdateSubResource nell'interfaccia della risorsa.
Effetti direct3D 10
L'uso del sistema Direct3D 10 Effects non rientra nell'ambito di questo articolo. Il sistema è stato scritto per sfruttare appieno i vantaggi dell'architettura offerti da Direct3D 10. Per altri dettagli sull'uso, vedi la sezione Effetti (Direct3D 10 ).
HLSL senza effetti
La pipeline direct3D 10 shader può essere guidata senza l'uso del sistema Direct3D 10 Effects. Si noti che in questa istanza, tutti i buffer costanti, gli shader, il campionatore e l'associazione di trame devono essere gestiti dall'applicazione stessa. Per altre informazioni, vedere il collegamento di esempio e le sezioni seguenti di questo documento:
Compilazione shader
Il compilatore Direct3D 10 HLSL offre miglioramenti alla definizione del linguaggio HLSL e quindi ha la possibilità di operare in 2 modalità. Per il supporto completo delle funzioni intrinseche e della semantica dello stile Direct3D 9, la compilazione deve essere richiamata usando il flag COMPATIBILITY MODE che può essere specificato in base alla compilazione.
Il modello di shader 4.0 specifico semantica del linguaggio HLSL e funzioni intrinseche per Direct3D 10 è disponibile in HLSL. Modifiche principali nella sintassi da Direct3D 9 HLSL per prendere la maggior parte degli avvisi sono nell'area di accesso alle trame. La nuova sintassi è l'unica forma supportata dal compilatore al di fuori della modalità di compatibilità.
Nota
Le API di tipo compilatore Direct3D 10 (D3D10CompileShader e D3D10CompileEffectFromMemory) vengono fornite dai runtime Direct3D 10, 10.1 e 11 eseguiti in Windows Vista e versioni successive. Le API di tipo compilatore Direct3D 10 hanno la stessa funzionalità del compilatore HLSL fornito in DirectX SDK (dicembre 2006). Questo compilatore HLSL non supporta i profili Direct3D 10.1 (vs_4_1, ps_4_1, gs_4_1, fx_4_1) e manca una serie di ottimizzazioni e miglioramenti. È possibile ottenere un compilatore HLSL che supporta i profili Direct3D 10.1 dalla versione legacy di DirectX SDK più recente. Per informazioni sull'SDK DirectX legacy, vedere Dove si trova DirectX SDK?. È possibile ottenere la versione più recente di HLSL Fxc.exe compilatore da riga di comando e API D3DCompiler da Windows SDK.
Creazione di risorse shader
La creazione di istanze di shader compilate al di fuori del sistema Direct3D 10 Effects viene eseguita in modo molto simile a Direct3D 9, tuttavia, in Direct3D 10, è importante mantenere la firma di input dello shader per un uso successivo. La firma viene restituita per impostazione predefinita come parte del BLOB dello shader, ma può essere estratta per ridurre i requisiti di memoria, se necessario. Per altri dettagli, vedere Uso degli shader in Direct3D 10.
Interfaccia del livello reflection shader
Il livello di reflection dello shader è l'interfaccia in base alla quale è possibile ottenere informazioni sui requisiti dello shader. Ciò è particolarmente utile quando si creano collegamenti all'assembly di input (vedere di seguito) in cui potrebbe essere necessario attraversare i requisiti di input dello shader per assicurarsi di fornire la struttura di input corretta allo shader. È possibile creare un'istanza dell'interfaccia del livello di reflection contemporaneamente alla creazione di un'istanza di uno shader compilato.
Il livello di reflection dello shader sostituisce i metodi D3DX9 che forniscono funzionalità simili. Ad esempio, IsParameterUsed viene sostituito dal metodo GetDesc.
Layout dell'assembler di input - Vertex Shader/Input Stream Linkage
Input Assembler (IA) sostituisce la dichiarazione di flusso dei vertici in stile Direct3D 9 e la struttura della descrizione è molto simile in forma. La differenza principale che l'IA porta è che l'oggetto layout IA creato deve eseguire direttamente il mapping a un formato specifico di firma di input dello shader. L'oggetto di mapping creato per collegare il flusso di input allo shader può essere usato in un numero qualsiasi di shader in cui la firma di input dello shader corrisponde a quella dello shader usato per creare il layout di input.
Per guidare al meglio la pipeline con dati statici, è consigliabile prendere in considerazione le permutazioni del formato del flusso di input per possibili firme di input dello shader e creare le istanze dell'oggetto di layout IA il prima possibile e riutilizzarle laddove possibile.
Impatto della rimozione del codice non recapitabili dello shader
La sezione seguente descrive in dettaglio una differenza significativa tra Direct3D 9 e Direct3D 10 che probabilmente richiede un'attenta gestione nel codice del motore. Gli shader che contengono espressioni condizionali spesso hanno alcuni percorsi di codice rimossi come parte del processo di compilazione. In Direct3D 9, è possibile rimuovere due tipi di input (contrassegnati per la rimozione) quando non usati: input di firma (come l'esempio seguente) e input costanti. Se la fine del buffer costante contiene voci inutilizzate, la dichiarazione di dimensione nello shader rifletterà le dimensioni del buffer costante senza le voci inutilizzate alla fine. Entrambi questi tipi di input rimangono nelle firme o nei buffer costanti Direct3D 10 con un'eccezione speciale nel caso di input costanti inutilizzate alla fine di un buffer costante. Ciò può avere un impatto sul motore quando si gestiscono shader di grandi dimensioni e si creano layout di input. Gli elementi rimossi dalle ottimizzazioni del codice non recapitabili nel compilatore devono comunque essere dichiarati nella struttura di input. Questo concetto è illustrato nell'esempio seguente:
Esempio di struttura di input vertex shader
struct VS_INPUT
{
float4 pos: SV_Position;
float2 uv1 : Texcoord1;
float2 uv2 : Texcoord2; *
};
* Rimozione del codice morto Direct3D 9 rimuoverebbe la dichiarazione nello shader a causa della rimozione condizionale del codice non risolto
float4x4 g_WorldViewProjMtx;
static const bool g_bLightMapped = false; // define a compile time constant
VS_INPUT main(VS_INPUT i)
{
VS_INPUT o;
o.pos = mul( i.pos, g_WorldViewProjMtx);
o.uv1 = i.uv1;
if ( g_bLightMapped )
{
o.uv2 = i.uv2;
}
return o;
}
In alternativa, è possibile rendere ancora più evidente che la costante è una costante in fase di compilazione con la dichiarazione seguente:
#define LIGHT_MAPPED false
Nell'esempio precedente, in Direct3D 9, l'elemento uv2 verrà rimosso a causa di ottimizzazioni del codice non recapitabili nel compilatore. In Direct3D 10 il codice non recapitabile verrà comunque rimosso, ma il layout dell'assembler di input dello shader richiede che esista la definizione dei dati di input. Il livello di reflection dello shader fornisce i mezzi per gestire questa situazione in modo generico in cui è possibile attraversare i requisiti di input dello shader e assicurarsi di fornire una descrizione completa del mapping della firma del flusso di input allo shader.
Ecco una funzione di esempio per rilevare l'esistenza di un nome/indice semantico in una firma di funzione:
// Returns true if the SemanticName / SemanticIndex is used in the input signature.
// pReflector is a previously acquired shader reflection interface.
bool IsSignatureElementExpected(ID3D10ShaderReflection *pReflector, const LPCSTR SemanticName, UINT SemanticIndex)
{
D3D10_SHADER_DESC shaderDesc;
D3D10_SIGNATURE_PARAMETER_DESC paramDesc;
Assert(pReflector);
Assert(SemanticName);
pReflector->GetDesc(&shaderDesc);
for (UINT k=0; k<shaderDesc.InputParameters; k++)
{
pReflector->GetInputParameterDesc( k, ¶mDesc);
if (wcscmp( SemanticName, paramDesc.SemanticName)==0 && paramDesc.SemanticIndex == SemanticIndex)
return true;
}
return false;
}
Creazione di oggetti di stato
Quando si esegue la conversione del codice del motore, può essere utile usare inizialmente un set predefinito di oggetti di stato e disabilitare tutte le impostazioni di stato/stato di rendering del dispositivo Direct3D 9. Ciò causerà il rendering degli artefatti, ma è il modo più rapido per rendere operativi le operazioni. In un secondo momento è possibile costruire un sistema di gestione degli oggetti di stato che può usare una chiave composta per consentire il riutilizzo massimo del numero massimo di oggetti di stato in uso.
Conversione di trame
Formati di file supportati
Le funzioni D3DXxxCreateXXX e D3DXxxSaveXXX che creano o salvano una trama da o in un file grafico (ad esempio, D3DX10CreateTextureFromFile) supportano un set diverso di formati di file in Direct3D 10 rispetto a quanto fatto in Direct3D 9:
| Formato file | Direct3D 9 | Direct3D 10 |
|---|---|---|
| .bmp | yes | yes |
| JPG | yes | yes |
| .tga | yes | |
| .png | yes | yes |
| .dds | yes | yes |
| .Ppm | yes | |
| .dib | yes | |
| .Hdr | yes | |
| Pfm | yes | |
| TIFF | yes | |
| .gif | yes | |
| .tif | yes |
Per informazioni dettagliate, confrontare le enumerazioni direct3D 9 D3DXIMAGE_FILEFORMAT con le enumerazioni D3DX10_IMAGE_FILE_FORMAT per Direct3D 10.
Nota
La libreria di utilità D3DX (D3DX 9, D3DX 10 e D3DX 11) è deprecata per Windows 8. Per l'elaborazione di file di trama, è consigliabile usare DirectXTex.
Mapping dei formati di trama
La tabella seguente illustra il mapping dei formati di trama da Direct3D 9 a Direct3D 10. Qualsiasi contenuto in formati non disponibili in DXGI dovrà essere convertito dalle routine di utilità.
| Formato Direct3D 9 | Formato Direct3D 10 |
|---|---|
| D3DFMT_UNKNOWN | DXGI_FORMAT_UNKNOWN |
| D3DFMT_R8G8B8 | Non disponibile |
| D3DFMT_A8R8G8B8 | DXGI_FORMAT_B8G8R8A8_UNORM & DXGI_FORMAT_B8G8R8A8_UNORM_SRGB¹ |
| D3DFMT_X8R8G8B8 | DXGI_FORMAT_B8G8R8X8_UNORM & DXGI_FORMAT_B8G8R8X8_UNORM_SRGB¹ |
| D3DFMT_R5G6B5 | DXGI_FORMAT_B5G6R5_UNORM² |
| D3DFMT_X1R5G5B5 | Non disponibile |
| D3DFMT_A1R5G5B5 | DXGI_FORMAT_B5G5R5A1_UNORM² |
| D3DFMT_A4R4G4B4 | DXGI_FORMAT_B4G4R4A4_UNORM |
| D3DFMT_R3G3B2 | Non disponibile |
| D3DFMT_A8 | DXGI_FORMAT_A8_UNORM |
| D3DFMT_A8R3G3B2 | Non disponibile |
| D3DFMT_X4R4G4B4 | Non disponibile |
| D3DFMT_A2B10G10R10 | DXGI_FORMAT_R10G10B10A2 |
| D3DFMT_A8B8G8R8 | DXGI_FORMAT_R8G8B8A8_UNORM e DXGI_FORMAT_R8G8B8A8_UNORM_SRGB |
| D3DFMT_X8B8G8R8 | Non disponibile |
| D3DFMT_G16R16 | DXGI_FORMAT_R16G16_UNORM |
| D3DFMT_A2R10G10B10 | Non disponibile |
| D3DFMT_A16B16G16R16 | DXGI_FORMAT_R16G16B16A16_UNORM |
| D3DFMT_A8P8 | Non disponibile |
| D3DFMT_P8 | Non disponibile |
| D3DFMT_L8 | DXGI_FORMAT_R8_UNORM Nota: usare .r swizzle nello shader per duplicare il rosso in altri componenti per ottenere il comportamento D3D9. |
| D3DFMT_A8L8 | DXGI_FORMAT_R8G8_UNORM Nota: usare swizzle .rrrg nello shader per duplicare il rosso e spostare il verde nei componenti alfa per ottenere il comportamento D3D9. |
| D3DFMT_A4L4 | Non disponibile |
| D3DFMT_V8U8 | DXGI_FORMAT_R8G8_SNORM |
| D3DFMT_L6V5U5 | Non disponibile |
| D3DFMT_X8L8V8U8 | Non disponibile |
| D3DFMT_Q8W8V8U8 | DXGI_FORMAT_R8G8B8A8_SNORM |
| D3DFMT_V16U16 | DXGI_FORMAT_R16G16_SNORM |
| D3DFMT_W11V11U10 | Non disponibile |
| D3DFMT_A2W10V10U10 | Non disponibile |
| D3DFMT_UYVY | Non disponibile |
| D3DFMT_R8G8_B8G8 | DXGI_FORMAT_G8R8_G8B8_UNORM (in DX9 i dati sono stati ridimensionati di 255,0f, ma questo può essere gestito nel codice shader). |
| D3DFMT_YUY2 | Non disponibile |
| D3DFMT_G8R8_G8B8 | DXGI_FORMAT_R8G8_B8G8_UNORM (in DX9 i dati sono stati ridimensionati di 255,0f, ma questo può essere gestito nel codice shader). |
| D3DFMT_DXT1 | DXGI_FORMAT_BC1_UNORM & DXGI_FORMAT_BC1_UNORM_SRGB |
| D3DFMT_DXT2 | DXGI_FORMAT_BC1_UNORM & DXGI_FORMAT_BC1_UNORM_SRGB Nota: DXT1 e DXT2 sono uguali dal punto di vista dell'API/hardware... solo la differenza è "alfa premoltiplicata", che può essere rilevata da un'applicazione e non richiede un formato separato. |
| D3DFMT_DXT3 | DXGI_FORMAT_BC2_UNORM & DXGI_FORMAT_BC2_UNORM_SRGB |
| D3DFMT_DXT4 | DXGI_FORMAT_BC2_UNORM & DXGI_FORMAT_BC2_UNORM_SRGB Nota: DXT3 e DXT4 sono uguali dal punto di vista dell'API/hardware... solo la differenza è "alfa premoltiplicata", che può essere rilevata da un'applicazione e non richiede un formato separato. |
| D3DFMT_DXT5 | DXGI_FORMAT_BC3_UNORM & DXGI_FORMAT_BC3_UNORM_SRGB |
| D3DFMT_D16 & D3DFMT_D16_LOCKABLE | DXGI_FORMAT_D16_UNORM |
| D3DFMT_D32 | Non disponibile |
| D3DFMT_D15S1 | Non disponibile |
| D3DFMT_D24S8 | Non disponibile |
| D3DFMT_D24X8 | Non disponibile |
| D3DFMT_D24X4S4 | Non disponibile |
| D3DFMT_D16 | DXGI_FORMAT_D16_UNORM |
| D3DFMT_D32F_LOCKABLE | DXGI_FORMAT_D32_FLOAT |
| D3DFMT_D24FS8 | Non disponibile |
| D3DFMT_S1D15 | Non disponibile |
| D3DFMT_S8D24 | DXGI_FORMAT_D24_UNORM_S8_UINT |
| D3DFMT_X8D24 | Non disponibile |
| D3DFMT_X4S4D24 | Non disponibile |
| D3DFMT_L16 | DXGI_FORMAT_R16_UNORM Nota: usare .r swizzle nello shader per duplicare il rosso in altri componenti per ottenere il comportamento D3D9. |
| D3DFMT_INDEX16 | DXGI_FORMAT_R16_UINT |
| D3DFMT_INDEX32 | DXGI_FORMAT_R32_UINT |
| D3DFMT_Q16W16V16U16 | DXGI_FORMAT_R16G16B16A16_SNORM |
| D3DFMT_MULTI2_ARGB8 | Non disponibile |
| D3DFMT_R16F | DXGI_FORMAT_R16_FLOAT |
| D3DFMT_G16R16F | DXGI_FORMAT_R16G16_FLOAT |
| D3DFMT_A16B16G16R16F | DXGI_FORMAT_R16G16B16A16_FLOAT |
| D3DFMT_R32F | DXGI_FORMAT_R32_FLOAT |
| D3DFMT_G32R32F | DXGI_FORMAT_R32G32_FLOAT |
| D3DFMT_A32B32G32R32F | DXGI_FORMAT_R32G32B32A32_FLOAT |
| D3DFMT_CxV8U8 | Non disponibile |
| D3DDECLTYPE_FLOAT1 | DXGI_FORMAT_R32_FLOAT |
| D3DDECLTYPE_FLOAT2 | DXGI_FORMAT_R32G32_FLOAT |
| D3DDECLTYPE_FLOAT3 | DXGI_FORMAT_R32G32B32_FLOAT |
| D3DDECLTYPE_FLOAT4 | DXGI_FORMAT_R32G32B32A32_FLOAT |
| D3DDECLTYPED3DCOLOR | Non disponibile |
| D3DDECLTYPE_UBYTE4 | DXGI_FORMAT_R8G8B8A8_UINT Nota: shader ottiene valori UINT, ma se sono necessari float integrali di stile Direct3D 9 (0,0f, 1,0f... 255.f), UINT può essere convertito in float32 in shader. |
| D3DDECLTYPE_SHORT2 | DXGI_FORMAT_R16G16_SINT Nota: shader ottiene valori SINT, ma se sono necessari float integrali di stile Direct3D 9, SINT può essere semplicemente convertito in float32 in shader. |
| D3DDECLTYPE_SHORT4 | DXGI_FORMAT_R16G16B16A16_SINT Nota: shader ottiene valori SINT, ma se sono necessari float integrali di stile Direct3D 9, SINT può essere semplicemente convertito in float32 nello shader. |
| D3DDECLTYPE_UBYTE4N | DXGI_FORMAT_R8G8B8A8_UNORM |
| D3DDECLTYPE_SHORT2N | DXGI_FORMAT_R16G16_SNORM |
| D3DDECLTYPE_SHORT4N | DXGI_FORMAT_R16G16B16A16_SNORM |
| D3DDECLTYPE_USHORT2N | DXGI_FORMAT_R16G16_UNORM |
| D3DDECLTYPE_USHORT4N | DXGI_FORMAT_R16G16B16A16_UNORM |
| D3DDECLTYPE_UDEC3 | Non disponibile |
| D3DDECLTYPE_DEC3N | Non disponibile |
| D3DDECLTYPE_FLOAT16_2 | DXGI_FORMAT_R16G16_FLOAT |
| D3DDECLTYPE_FLOAT16_4 | DXGI_FORMAT_R16G16B16A16_FLOAT |
| FourCC 'ATI1' | DXGI_FORMAT_BC4_UNORM |
| FourCC 'ATI2' | DXGI_FORMAT_BC5_UNORM |
¹DXGI 1.1, incluso nel runtime Direct3D 11, include formati BGRA. Tuttavia, il supporto per questi formati è facoltativo per i dispositivi Direct3D 10 e 10.1 con driver implementati per Windows Display Driver Model (WDDM) per Windows Vista (WDDM 1.0). È consigliabile usare invece DXGI_FORMAT_R8G8B8A8_UNORM. In alternativa, è possibile creare il dispositivo con D3D10_CREATE_DEVICE_BGRA_SUPPORT per assicurarsi di supportare solo i computer con il runtime Direct3D 11.0 e un driver WDDM 1.1 o versione successiva.
²DXGI 1.0 ha definito formati 5:6:5 e 5:5:5:1, ma non supportati dal runtime Direct3D 10.x o Direct3D 11.0. Questi formati sono facoltativamente supportati con DXGI 1.2 nel runtime di DirectX 11.1, obbligatorio per le schede video di livello 11.1 e WDDM 1.2 (modello di driver di visualizzazione a partire da Windows 8) e già supportato nei livelli di funzionalità 10level9.
²DXGI 1.2 ha introdotto il formato 4:4:4:4. Questo formato è facoltativamente supportato nel runtime di DirectX 11.1, necessario per le schede video di livello 11.1 e i driver WDDM 1.2 e già supportati nei livelli di funzionalità 10level9.
Per i formati non compressi, DXGI ha limitato il supporto per modelli di formato pixel arbitrari; tutti i formati non compressi devono essere di tipo RGBA. Ciò potrebbe richiedere lo scorrimento rapido dei formati pixel degli asset esistenti, che è consigliabile calcolare come passaggio di pre-elaborazione offline, se possibile.
Porting shader
Gli shader Direct3D 10 vengono creati in HLSL
Direct3D 10 limita l'uso del linguaggio assembly solo a scopo di debug, pertanto qualsiasi assembly shader scritto a mano usato in Direct3D 9 dovrà essere convertito in HLSL.
Firme shader e collegamento
In precedenza in questo documento sono stati illustrati i requisiti per il collegamento all'assembly di input dell'assembly di input al vertex shader (vedere sopra). Si noti che il runtime di Direct3D 10 ha anche ristretto i requisiti per la fase di collegamento tra shader. Questa modifica influirà sulle origini dello shader in cui l'associazione tra le fasi potrebbe non essere stata descritta completamente in Direct3D 9. Ad esempio:
VS_OUTPUT PS_INPUT
float4 pos : SV_POSITION; float4 pos : SV_POSITION;
float4 uv1 : TEXCOORD1; float4 uv1 : TEXCOORD1;
float4x3 tangentSp : TEXCOORD2; float4 tangent : TEXCOORD2; *
float4 Color : TEXCOORD6; float4 color : TEXCOORD6;
* Broken VS - PS Linkage - anche se il pixel shader potrebbe non essere interessato alla matrice completa, il collegamento deve specificare il float4x3 completo.
Si noti che la semantica di collegamento tra le fasi deve corrispondere esattamente, ma gli input delle fasi di destinazione possono essere un prefisso dei valori restituiti. Nell'esempio precedente, il pixel shader potrebbe avere posizione e texcoord1 come unici input, ma non poteva avere la posizione e il texcoord2 come unici input a causa dei vincoli di ordinamento.
Collegamenti alla fase shader HLSL
Il collegamento tra shader può verificarsi in uno dei punti seguenti nella pipeline:
- Assembler di input in Vertex Shader
- Vertex Shader in Pixel Shader
- Vertex Shader to Geometry Shader
- Vertex Shader to Stream Output
- Geometry Shader to Pixel Shader
- Geometry Shader to Stream Out
Buffer costanti
Per semplificare la conversione del contenuto da Direct3D 9, un approccio iniziale alla gestione costante all'esterno del sistema Effects potrebbe comportare la creazione di un singolo buffer costante contenente tutte le costanti richieste. È importante per le prestazioni ordinare le costanti in buffer in base alla frequenza prevista di aggiornamento. Questa organizzazione ridurrà al minimo la quantità di set di costanti ridondanti.
Piani di ritaglio utente in HLSL al livello di funzionalità 9 e superiore
A partire da Windows 8, è possibile usare l'attributo della funzione Clipplanes in una dichiarazione di funzione HLSL anziché SV_ClipDistance per rendere il lavoro dello shader a livello di funzionalità 9_x nonché il livello di funzionalità 10 e superiore. Per altre info, vedi Piani clip utente su hardware di livello 9.
Differenze aggiuntive per Direct3D 10 da controllare
Numeri interi come input
In Direct3D 9 non è disponibile alcun supporto hardware reale per i tipi di dati Integer, ma l'hardware Direct3D 10 supporta tipi integer espliciti. Se nel buffer dei vertici sono presenti dati a virgola mobile, è necessario disporre di un input float. In caso contrario, un tipo integer sarà la rappresentazione del criterio di bit del valore a virgola mobile. Un tipo integer non è consentito per un input pixel shader, a meno che il valore non sia contrassegnato per nessuna interpolazione (vedere Modificatori di interpolazione).
Cursori del mouse
Nelle versioni precedenti di Windows, le routine standard del cursore del mouse GDI non funzionavano correttamente su tutti i dispositivi esclusivi a schermo intero. Le API SetCursorProperties, ShowCursor e SetCursorPosition sono state aggiunte per gestire questi casi. Poiché la versione di Windows Vista di GDI comprende completamente le superfici DXGI , non c'è bisogno di questa API specializzata del cursore del mouse, quindi non esiste alcun equivalente Direct3D 10. Le applicazioni Direct3D 10 devono invece usare le routine standard del cursore del mouse GDI per i cursori del mouse.
Mapping di texel a pixel in Direct3D 10
In Direct3D 9, i centri texel e i centri pixel erano a metà unità di distanza (vedere Mapping diretto di texel a pixel (Direct3D 9)). In Direct3D 10, i centri texel sono già a metà unità, quindi non è necessario spostare le coordinate dei vertici.
Il rendering di quad a schermo intero è più semplice con Direct3D 10. I quad a schermo intero devono essere definiti in clipspace (-1,1) e semplicemente passati attraverso il vertex shader senza modifiche. In questo modo, non è necessario ricaricare il buffer dei vertici ogni volta che cambia la risoluzione dello schermo e non c'è alcun lavoro aggiuntivo nel pixel shader per modificare le coordinate della trama.
Modifiche al comportamento di conteggio dei riferimenti
A differenza delle versioni precedenti di Direct3D, le varie funzioni Set non conterranno un riferimento agli oggetti dispositivi. Ciò significa che l'applicazione deve garantire che contenga un riferimento sull'oggetto per tutto il tempo necessario per associare l'oggetto alla pipeline. Quando il conteggio dei riferimenti dell'oggetto scende a zero, l'oggetto verrà scollegato dalla pipeline man mano che viene eliminato definitivamente. Questo stile di conservazione dei riferimenti è noto anche come trattenente di riferimento debole, pertanto ogni posizione di associazione nell'oggetto Device contiene un riferimento debole all'interfaccia/oggetto. Se non diversamente indicato in modo esplicito, questo comportamento deve essere assunto per tutti i metodi Set. Ogni volta che la distruzione di un oggetto causa l'impostazione di un punto di associazione su NULL , il livello di debug genererà un avviso. Si noti che le chiamate ai metodi Get del dispositivo, ad esempio OMGetRenderTargets, aumentano il numero di riferimenti degli oggetti restituiti.
Testare il livello cooperativo
La funzionalità di TestCooperativeLevel dell'API Direct3D 9 è analoga all'impostazione del DXGI_PRESENT_TEST quando si chiama Present.
StretchRect
Una funzione simile al metodo IDirect3D 9 IDirect3DDevice9::StretchRect non è disponibile in Direct3D 10 e 10.1. Per copiare le superfici delle risorse, usare ID3D10Device::CopySubresourceRegion. Per le operazioni di ridimensionamento, eseguire il rendering in una trama usando il filtro delle trame. Per convertire le superfici MSAA in superfici non MSAA, usare ID3D10Device::ResolveSubresource.
Differenze aggiuntive di Direct3D 10.1
Windows Vista con Service Pack 1 (SP1) includeva un aggiornamento secondario per Direct3D 10 e Direct3D 10.1, che esponeva le funzionalità hardware aggiuntive seguenti:
- Shader MSAA per campione
- Readback profondità MSAA
- Modalità di fusione indipendenti per ogni destinazione di rendering
- Matrici mappa cubo
- Eseguire il rendering in formati compressi a blocchi (BC)
L'aggiornamento di Direct3D 10.1 ha aggiunto il supporto per le nuove interfacce seguenti, derivate dalle interfacce esistenti:
L'aggiornamento di Direct3D 10.1 include anche le strutture aggiuntive seguenti:
L'API Direct3D 10.1 include un nuovo concetto denominato livello di funzionalità. Questo concetto significa che è possibile usare l'API Direct3D 10.1 per l'unità hardware Direct3D 10.0 (D3D10_FEATURE_LEVEL_10_0) o Direct3D 10.1 (D3D10_FEATURE_LEVEL_10_1). Poiché l'API Direct3D 10.1 è derivata dalle interfacce Direct3D 10, le applicazioni possono creare un dispositivo Direct3D 10.1, quindi usarlo come dispositivo Direct3D 10.0, tranne dove sono necessarie nuove funzionalità specifiche della versione 10.1 (purché il livello di funzionalità D3D10_FEATURE_LEVEL_10_1 sia presente e supporti queste funzionalità).
Nota
I dispositivi Direct3D 10.1 possono usare i profili shader 10.0 HLSL esistenti (vs_4_0, ps_4_0, gs_4_0) e i nuovi profili 10.1 (vs_4_1, ps_4_1, gs_4_1) con istruzioni e funzionalità HLSL aggiuntive.
Windows 7 conteneva un aggiornamento secondario per l'API Direct3D 10.1 inclusa nel runtime direct3D 11. Questo aggiornamento aggiunge il supporto per i livelli di funzionalità seguenti:
Windows 7 ha anche aggiunto il supporto a Direct3D 10.1 per Windows Advanced Rasterization Platform (WARP). È possibile specificare un driver WARP usando D3D10_DRIVER_TYPE_WARP.
Per altre informazioni su Direct3D 10.1, vedere Funzionalità di Direct3D 10.1 e l'enumerazione D3D10_FEATURE_LEVEL1.
Argomenti correlati