Tramite il framework XNA i programmatori furono in grado di utilizzare il linguaggio .Net per sviluppare in modo unificato e semplice sia per PC che per XBox 360. Nonostante il successo però molti ritennero XNA troppo limitato al settore videoludico (la sua struttura è infatti studiata per sviluppare giochi da poter condividere sulla piattaforma Live di Microsoft). Le due principali carenze sono infatti che è troppo restrittitiva per applicazioni non videoludiche e che, per poter essere accessibile alla XBox 360, la tecnologia dovesse essere limitata alla versione DX9.

Sono però uscite negli anni le DirectX10 e le DirectX11 e da questo punto di vista Microsoft non ha pubblicato alcun componente .Net. Molti quindi fecero quello che Microsoft fece a quei tempi: creare un componente che portasse le DirectX in ambiente .Net. Esistono diversi gruppi che già portano avanti i loro progetti ed io, per necessità personali, ho realizzato il mio componente che ho deciso di mettere a vostra disposizione.

Il Managed DirectX 11 porta tutte le tecnologie incluse nelle DirectX in ambiente .Net 3.5 (quindi Visual Studio 2008 professional o express) permettendovi di utilizzare C# o VB.Net come linguaggio base per giochi e programmi.

Le tecnologie portate sono

• DXGI
• D3DX
• XNAMath
• Direct2D
• DirectWrite
• Direct3D10
• Direct3D11
• DirectInput
• XInput
• XAudio
• XAct

Ho cercato di mantenere una mappatura 1:1 tra il relativo componente C++ e quello .Net in modo da permettervi di utilizzare con facilità le guide ed i tutorial che si trovano in giro per C++. Tra gli esempi c'è la decisione di non utilizzare costruttori ma, come nella versione nativa, di lasciare ad oggetti come il Device o a funzioni statiche, incluse nella classe che si sta per creare, il compito di creare gli oggetti.

Allo stesso tempo però ho eliminato problemi tipici del C++ come l'obbligo di eliminare gli oggetti (compito che ho lasciato alla Garbage Collector) e l'utilizzo di puntatori a memorie (ad esempio la scrittura e lettura è affidata a comodi metodi generics a cui passare direttamente array di byte o strutture complesse).

Non esiste una guida all'utilizzo di questi componenti ma, al momento della pubblicazione di questa pagina, è in corso da parte mia la realizzazione di tutorial DirectX11 che utilizzeranno nei sorgenti queste librerie.

Vi lascio i cab con l'unica nota di non spacciarli per vostri ma di fare riferimento sempre a me come ideatore. Per il resto siete liberi di utilizzarli nei vostri progetti come meglio crediate.

Tornate a visitare questa pagina periodicamente per vedere update o bugfix

Release 13/06/2010

• Aggiornata alla SDK di Giugno 2010
• Aggiunte le versioni .Net 4.0

Librerie (1600kb)

Librerie + Tutorial (10Mb)

Vi lascio il link

Il geometry instancing è una tecnologia che permette di replicare un Vertex Buffer numerose volte in modo da creare copie di un oggetto a video in modo ottimizzato.

Tramite il geometry instancing possiamo caricare un soldato ed in un'unica istruzione di draw, mandarne a video migliaia di copie, ognuna con caratteristiche di posizione, colore o texture differenti l'uno dall'altro.

La cosa più interessante è la totale gestione in memoria video del processo, permettendo delle prestazioni impensabili normalmente. Infatti ogni volta che si esegue una istruzione di draw ci sono dati che passano dalla RAM alla scheda video o tra zone diverse di quest'ultima: sarà direttamente la GPU ad operare la moltiplicazione dei vertici e degli indici dell'oggetto.

Il geometry instancing prevede l'utilizzo di 2 vertex buffer: il primo contenente i vertici dell'oggetto, il secondo contenente un array di strutture dati specifiche per ogni copia. Ad esempio se vogliamo rappresentare 1000 oggetti, ognuno con posizione e colore diverso, dovremo creare una struttura contenente posizione e colore e crearne un array di 1000 elementi. La funzionalità geometry instancing non farà altro che fondere ogni vertice con ogni elemento del secondo buffer. Nel vertex shader troveremo una struttura di input che sarà la somma dei 2 buffer. Dal punto di vista dello shader sarà quindi sufficiente prevedere dei dati extra da utilizzare per modificare la posizione ed il colore dell'oggetto. Per prima cosa è necessario creare un buffer per contenere i dati

ID3D11Buffer* instanceBuffer;

this->stride=stride;
this->offset=0;
this->vertexCount=vertexCount;
D3D11_BUFFER_DESC bd;
bd.Usage = D3D11_USAGE_DYNAMIC;
bd.ByteWidth = stride * elementCount;
bd.BindFlags = D3D11_BIND_VERTEX_BUFFER;
bd.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
bd.MiscFlags = 0;

D3D11_SUBRESOURCE_DATA InitData;
InitData.pSysMem = data;

device->CreateBuffer( &bd, &InitData, &instanceBuffer);

Come vedete è simile a quanto usato per il vertex buffer. Per poter utilizzare l'instancing occorre creare un layout appropriato

D3D11_INPUT_ELEMENT_DESC layout[] =
{
{ "POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 },
{ "TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT, 0, 12, D3D11_INPUT_PER_VERTEX_DATA, 0 },
{ "EXTRADATA", 0, DXGI_FORMAT_R32G32B32A32_FLOAT, 1, 0, D3D11_INPUT_PER_INSTANCE_DATA, 1 },
};

Nell' instancing il layout è formato dalla somma dei due formati vertici. Il secondo buffer è descritto dalla seconda parte dell'array. Si può notare infatti che l'indice è impostato ad 1 e non a 0 (perchè sarà estratto dal secondo buffer), l'offset è a zero (perchè si conta l'offset del buffer, non totale del vertice) e si imposta il tipo ad Instance_Data. L'ultimo valore, instance_repetition, va impostato ad 1.

Ora quello che si dovrò fare in fase di rendering è passare i 2 vertex buffer contemporaneamente (quello con i dati e quello con i dati per l'instancing).

 Ad esempio nel caso del solo Vertex Buffer

device->IASetInputLayout(this->layout);
device->IASetPrimitiveTopology(D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST);
ID3D11Buffer* buffers[2]={vertexBuffer,instanceVertexBuffer};
UINT strideA[2]={stride,instanceStride};
UINT offsetA[2]={0,0};

device->IASetVertexBuffers(0,2,buffers,strideA,offsetA);
device->DrawInstanced(VertexCount,istanceCount,0,0);

O nel caso ci sia anche Index Buffer

device->IASetVertexBuffers(0,2,buffers,strideA,offsetA);
device->IASetIndexBuffer(indexBuffer,DXGI_FORMAT_R16_UINT,0);
device->DrawIndexedInstanced(FaceCount*3,istanceCount,0,0,0);

In questo esempio vedete come ho eseguito il rendering. Ho creato un array con due buffer e li ho passati al device insieme ai due stride ed i due offset. Nel mio esempio avrò uno stride di 20 byte per il primo vertex buffer (POSITION e TEXCOORD) e 16 per il secondo (EXTRADATA). Successivamente passo l'indexbuffer ed utilizzo l'istruzione DrawIndexedInstanced per mandare il rendering (gli si passa alla funzione il numero degli indici ed il numero di istance ossia quante copie dell'oggetto volete). Con la funzione DrawIndexedInstance potrete renderizzare oggetti da un minimo di zero ad un massimo pari al numero di elementi nel buffer dell'instance.

Nello shader non noterete differenza

struct VS_INPUT
{
float4 Pos : POSITION;
float2 tex:TEXCOORD;
float4 posIstance:EXTRADATA;
};

Ogni vertice del primo buffer sarà combinato con ogni vertice (anche se in realtà sono dati anche se gestiti come vertici). Quindi se abbiamo un cubo e 1000 vettori posizione otterremo 8 (vertici del cubo) * 1000 = 8000 vertici e quindi 8000 chiamate allo shader con tutte le combinazioni. Nello shader ad esempio potremo utilizzare il vettore per spostare il cubo in modo da assegnare ad ognuno una posizione diversa. Passando 4 float4 avrete una intera matrice. Potete passare quanti dati volete.

Nella struttura di input potete utilizzare un campo non definito nei due buffer con sintatti SV_InstanceID

uint indice:SV_InstanceID

Questo campo contiene l'indice dell'instanza che stiamo renderizzando (che varierà quindi da 0 a 999 nell'esempio).

Vi lascio al demo che renderizza fino a 1000 cubi contemporaneamente.

Demo CPP

Demo .Net

Download

Con la crescente potenza e versatilità delle schede video sono nate negli ultimi anni diverse tecnologie volte ad utilizzare la GPU per operazioni diverse dal rendering di grafica. Tra le tecnologie volte a questo scopo c’è ad esempio CUDA di nVidia, OpenCL e, nel caso di DirectX11, le Direct Compute.

Sotto il nome di Direct Compute c’è un sotto insieme di funzioni Direct3D per l’esecuzioni di calcoli matematici tramite l’utilizzo dei Compute Shaders, degli speciali Shader che anziché entrare nella pipeline grafica non fanno altro che leggere e scrivere su appositi buffer di memoria.

Al termine dell’operazione sarà sufficiente andare a leggere i dati da tale buffer e farci ciò che serve. Il vantaggio dei Compute Shader non è tanto nella potenza di calcolo per singola operazione ma per il fatto che sono ottimizzate per lavorare su vettori e soprattutto lavorano con un elevatissimo numero di processi in parallelo raggiungendo, se utilizzate correttamente, prestazioni irraggiungibili per qualsiasi CPU. Gli utilizzi spaziano dai giochi (esempio per l’intelligenza artificiale) alle applicazioni che con la grafica non c’entrano nulla come ad esempio funzioni statistiche.

Questo articolo introdurrà l’argomento che è di fatto vasto ed apre una quantità di scenari grandissima.

Un Compute Shader presenta molte caratteristiche che lo differenziano dagli altri Shader. Innanzitutto la funzione non restituisce nulla ma lavora attraverso l’uso di speciali buffer chiamati Unordered Access View. Questi buffer, passati al DeviceContext in modo simile ai normali Constant Buffer, permettono di leggere e scrivere all’interno di essi. Dal codice C++ verrà creato un buffer di tipo UAV (abbreviazione del nome completo) e all’interno dello shader sarà presente come variabile di una delle tipologie a disposizione.

• AppendStructuredBuffer
• Buffer
• ByteAddressBuffer
• ConsumeStructuredBuffer
• RWByteAddressBuffer
• RWStructuredBuffer
• RWTexture1D
• RWTexture1DArray
• RWTexture2D
• RWTexture2DArray
• RWTexture3D

Non tutte supportano sia lettura che scrittura (AppendStructuredBuffer ad esempio permette solo di aggiungere valori come fosse una lista). Alcune inoltre permettono anche il supporto a Template (Generics per i programmatori .Net e Java).

Esempio

RWStructuredBuffer buffer;

Dove MyStruct è una struttura a mio piacere.

Tutte queste avranno un unico corrispettivo nel codice, l’oggetto ID3D11UnorderedAccessView che di fatto è una vista su un ID3D11Buffer. Entrambi andranno gestiti in quanto il primo è una vista al secondo che sarà utilizzato per estrarre o inserire dati. Ecco come vengono creati

ID3D11Buffer* viewBuffer;

D3D11_BUFFER_DESC sbDesc ;

sbDesc.BindFlags = D3D11_BIND_UNORDERED_ACCESS | D3D11_BIND_SHADER_RESOURCE;

sbDesc.Usage = D3D11_USAGE_DEFAULT;

sbDesc.CPUAccessFlags = 0;

sbDesc.MiscFlags = D3D11_RESOURCE_MISC_BUFFER_STRUCTURED;

sbDesc.StructureByteStride = sizeOfStruct;

sbDesc.ByteWidth = sizeOfStruct * size;

hr = device->CreateBuffer(&sbDesc,NULL,&viewBuffer);

ID3D11UnorderedAccessView* view;

D3D11_UNORDERED_ACCESS_VIEW_DESC sbUAVDesc;

sbUAVDesc.Buffer.FirstElement=0;

sbUAVDesc.Buffer.Flags=0;

sbUAVDesc.Buffer.NumElements=TotalSize;

sbUAVDesc.Format = DXGI_FORMAT_UNKNOWN;

sbUAVDesc.ViewDimension = D3D11_UAV_DIMENSION_BUFFER;

hr=device->CreateUnorderedAccessView(viewBuffer,&sbUAVDesc,&view);

Non molto diversi dal consueto.

Attenzione:

1. Le opzioni MiscFlags del Buffer e Flags e Format dell’ UnorderedAccessView vanno impostate in base al tipo di buffer nel codice HLSL. Nell’esempio ho usato un RWStructuredBuffer ma ognuno varia. Consultate l’help per vedere ognuno cosa vuole.
2. La dimensione deve essere multipla di 32bit

Ora è necessario creare l’oggetto ID3D11ComputeShader, cosa che avviene in modo identico agli altri Shader. Quindi passiamo i dati al DeviceContext

context->CSSetShader(computeShader,NULL,0);

E passiamo i buffer UAV

context->CSSetUnorderedAccessViews(start,count,&views,NULL);

Il primo element è l’indice dell’array views di ID3D11UnorderedAccessView e count il numero di elementi da caricare. L’ultimo valore passato a NULL nell’esempio va utilizzato nel caso di buffer di tipo Append o Consume (nel primo caso una lista a cui aggiungere valori, nel secondo valori da cui estrarre dati). In questo caso è possibile passare un array di interi (uno per ogni buffer) che ci darà il numero iniziale di valori (ad esempio una lista append precedentemente riempita di 100 elementi può essere usata una seconda volta sovrascrivendo solo gli ultimi 50 valori e non tutti gli altri).

Ora si manda in esecuzione il codice tramite l’istruzione Dispatch che eseguirà la funzione il numero di volte che decideremo.

Context->Dispatch(X,Y,Z);

Prima però andiamo a spiegare come funziona il parallelismo. Il codice di un Compute Shader è una funzione HLSL eseguita tantissime volte in parallelo. Il numero di esecuzioni è indicato in gruppi tramite 3 valori interi XYZ come a rappresentare una scacchiera a 3 dimensioni. Ogni gruppo a sua volta ha 3 valori che indicano il numero Thread per ogni gruppo da eseguire. Il gruppo di Thread è un concetto importante in quanto un gruppo è in grado di condividere non solo un buffer UAV, ma anche variabili comuni.

Se ad esempio definisco una variabile in questo modo

groupshared float4 myVal;

Questa sarà condivisa in lettura e scrittura tra tutti i thread del gruppo come variabile di appoggio.

Ovviamente sarà impossibile prevedere l’ordine ed i tempi di esecuzione di ogni thread quindi sarà necessario gestire l’accesso contemporaneo agli oggetti. Ci sono tuttavia delle istruzioni in grado di sincronizzare i thread creando un’attesa finchè tutte le funzioni di un gruppo non siano arrivate allo stesso punto. Ad esempio GroupMemoryBarrier fa in modo che nessuna funzione di un gruppo non superi questa istruzione finchè gli altri thread dello stesso gruppo non hanno completato l’accesso alle variabili condivise mentre GroupMemoryBarrierWithGroupSync fa anche in modo che le istruzioni raggiungano esattamente questa funzione prima che tutte proseguino. Allo stesso modo ci sono funzioni che gestiscono l’accesso ai buffer UAV.

Il vantaggio delle variabili groupshared è la maggiore velocità e comodità di gestione. Thread di gruppi diversi comunicheranno invece solo tramite i buffer UAV e non potranno essere sincronizzati tra loro.

L’istruzione Dispatch indicherà il numero di gruppi da eseguire. Una scheda video DirectX11 gestisce a pieno le funzionalità ComputeShader ed è in grado di eseguire fino a 65536 gruppi per asse ossia quasi 300000 miliardi di gruppi mentre per ogni gruppo si può raggiungere un limite di 1024 thread per l’asse XY e 64 per l’asse Z. Ovviamente è un limite puramente teorico in quanto qualsiasi scheda video andrebbe in crash ma l’esecuzione di milioni di thread è un compito estremamente semplice per una scheda di fascia medio alta e tale valore non farà altro che migliorare nel tempo.

Vediamo ora come è strutturato un Compute Shader

Struct MyStruct

{

Float4 colore;

};

RWStructuredBuffer inOutBuff;

[numthreads( thread_group_size_x, thread_group_size_y, 1 )]

void CSMain( uint3 int idx = dispatchThreadID.y * threadIDInGroup : SV_GroupThreadID, uint3 groupID : SV_GroupID, uint groupIndex : SV_GroupIndex, uint3 dispatchThreadID : SV_DispatchThreadID )

{

//valori per riga

int stride = thread_group_size_x * N_THREAD_GROUPS_X;

//indice linearizzato

stride + dispatchThreadID.x;

inOutBuff [ idx ].colore= float4(1,1,1,1);

}

E’ possibile vedere una funzione CSMain che per semplicità non fa altro che valorizzare un RWStructeredBuffer con un float4 contenente tutti 1. L’attributo numthreads indica quanti thread per asse XYZ la scheda eseguirà.

Vediamo anche che il metodo non restituisce nulla e che ha in ingresso diversi valori.

• SV_GroupThreadID: indica il thread del gruppo eseguito. Sono 3 valori che vanno da 0 ai valori passati a numthreads per ogni asse
• SV_GroupID: restituisce l’ID del gruppo. Sono 3 valori che variano da 0 al valore passato al metodo Dispatch del DeviceContext
• SV_GroupIndex: indica l’id del gruppo ma come valore unico da 0 ai valori X*Y*Z di numthreads
• SV_DispatchThreadID: unisce GroupThreadID e GroupID. I valori andranno da 0 al prodotto tra quello di numthreads e Dispatch per ogni asse. Se quindi abbiamo 32 thread per asse e passiamo al metodo Dispatch il valore 4 allora si andrà da 0 a 127 incluso

Questi valori ci permettono di sapere in quale punto ci troviamo. Ecco come ad esempio possiamo ottenere un valore consecutivo unico per ogni thread

int stride = numthreadsX * numDispatchX;

int idx = dispatchThreadID.y * stride + dispatchThreadID.x;

Il valore stride è il numero di thread totali lungo la X mentre idx è il valore unico che ci identificherà il thread. Le costanti numthreadsX e numDispatchX saranno definite da noi in modo che coincidano con quelle definite nello shader e nel metodo Dispatch.

Al termine del metodo Dispatch possiamo leggere il risultato facendo una copia del buffer associato all’UAV su uno di tipo Staging e facendo l’operazione di Map.

Attenzione: il metodo Dispatch è asincrono. Significa che il codice continuerà a funzionare anche se lo shader non ha terminato il suo compito a meno di funzioni che accedano al buffer come appunto Map. Un’altra istruzione che forza la conclusione del codice compute shader è il metodo Flush del DeviceContext, usato anche per la demo. Normalmente sarà invece preferibile andare avanti con il rendering mentre la scheda termina il calcolo.

Oltre alla possibilità di usare buffer UAV il Compute Shader può usare i normali ConstantBuffer e le Texture. Al contrario i buffer UAV possono essere usati anche nei Pixel Shader.

L’argomento è tutt’altro che esaurito ma vi lascio ad un primo esempio che esegue 64 x 64 gruppi di threads da 32x32, un totale di quasi 5 milioni di esecuzioni. Il calcolo eseguito è la formula di Mac Laurin dell’esponenziale. Ai fini del tutorial non è necessario sapere come funziona ma vi rimando per cultura personale a quello che è uno dei tanti sgraditi argomenti matematici delle facoltà universitarie.

Il rapporto è stato di 6-7 secondi quando eseguito dalla CPU a meno di 20 ms quando eseguito dalla scheda video. Il confronto è quindi impietoso e la CPU ne esce sconfitta.

Come ultimi appunti ricordo che è possibile usare i compute shader anche su schede che non supportano le DirectX11 con alcune limitazioni quali l’obbligo di usare solo 1 come valore per i Threads sull’asse Z e massimo 768 come valori su XY. Anche la dimensione della memoria condivisa scende da 32kb a 16kb.

Vi lascio l’esempio, in futuro ci sarà modo di approfondire il Compute Shader con esempi di come sfruttarne la potenza.

Demo CPP

Demo .Net

Una delle cose fondamentali utilizzando DirectX è il poter accedere alle risorse contenute nei buffer, che siano Constant Buffer, Texture o Vertex Buffer.

Ogni risorsa è creata in modo da poter essere letta o scritta solamente dalla GPU o dalla CPU. Questo ad esempio può significare che una certa risorsa può essere creata per poter essere letta dalla GPU (esempio una texture quando viene mandata a video) e scritta dalla CPU (per poter essere modificata), o viceversa oppure essere gestita completamente solamente dalla GPU o solamente dalla CPU.

In Direct3D11 infatti esistono 4 tipi di usage, ossia le caratteristiche di utilizzo:

• D3D11_USAGE_DEFAULT  : può essere letta e scritta solo dalla GPU (esempio di lettura è il vertex buffer, mentre quello in scrittura è un render target, ossia una texture su cui si fa il rendering)
• D3D11_USAGE_IMMUTABLE : può essere utilizzata solamente in lettura dalla GPU
• D3D11_USAGE_DYNAMIC  : può essere letta dalla GPU e scritta dalla CPU (ad esempio per creare un vertex buffer che deve cambiare continuamente)
• D3D11_USAGE_STAGING  : può essere letta e scritta solo dalla CPU

Non tutte le risorse possono essere create in tutte le modalità. Ad esempio in Staging non possiamo creare una texture. Questo porterebbe a pensare che solo alcune tipologie di risorse possano essere lette. Inoltre come si vede solo la modalità Staging ha funzionalità di lettura da CPU e quindi è l'unica che può essere letta e modificata da codice, ma allo stesso tempo non si può utilizzare per il rendering.

In Direct3D11 si utilizzano quindi le funzioni di Copy che permettono di copiare una risorsa tra buffer. Potete quindi copiare risorse da una risorsa di tipo Default, Immutable e Dynamic in una di tipo Staging, modificarla e ricopiarla sul buffer di origine.

L'unica risorsa su cui non si può andare a scrivere è solo quella definita come Immutable. Per creare una risorsa di staging si utilizza la classica forma di creazione di un buffer con BindFlags impostato a zero, usage a Staging ed CPUAccessFlags in lettura e scrittura.

D3D11_BUFFER_DESC bd;

bd.ByteWidth = stride * vertexCount;

bd.MiscFlags = 0;

bd.BindFlags = 0;

bd.Usage = D3D10_USAGE_STAGING;

bd.CPUAccessFlags = D3D11_CPU_ACCESS_READ | D3D11_CPU_ACCESS_WRITE;

ID3D11Buffer* buffer;
HRESULT hr=device->CreateBuffer( &bd, NULL, &buffer );

Per poter utilizzare la funzionalità di copia dovete creare una risorsa di dimensione uguale a quella di origine

A questo punto potete utilizzare le funzionalità di copia

deviceContext->CopyResource(buffer,vertexBuffer);

Con questa istruzione ho copiato un vertexBuffer su uno staging.

Ora dovrete andare a leggere le risorse. Per farlo si utilizza l'istruzione Map presente nel DeviceContext.

Questa è la novità rispetto a Direct3D10 in quanto ora è il Context a gestire l’operazione di Map e non il Buffer stesso.

D3D11_MAPPED_SUBRESOURCE mapped;

hr = context->Map(buffer,0,D3D11_MAP_READ,0,&mapped);

//QUI MODIFICHERETE I DATI

context->Unmap(buffer,0);

L'istruzione map restituisce una struttura mapped che contiene un puntatore pData. Su questo puntatore potrete fare tutte le operazioni che vorrete. Nel nostro caso abbiamo usato il parametro D3D11_MAP_READ ma potete usare anche l’opzione WRITE o entrambe. L’importante è che siano supportate dal tipo di buffer (Staging le supporta entrambe). Alla funzione map vengono passati sia il buffer che altri valori che andrà a spiegare.

Quando avete finito dovrete utilizzare l'istruzione UnMap per liberare le risorse. Ora la struttura mapped è sganciata dal buffer ed andarci a leggere o scrivere potrà generare errori.

A questo punto potete nuovamente copiare il buffer modificato sul buffer originario ed utilizzarlo per il rendering.

Ora i parametri. L’ultimo zero indica i tempi di attesa consentiti. Il valore 0 indica che l’istruzione aspetterà che la risorsa sia disponibile mentre D3D11_MAP_FLAG_DO_NOT_WAIT potrà generare errori se andiamo a chiedere una risorsa mentre è occupata (problemi che si potrebbero generare soprattutto in multithreating). Il secondo parametro invece indica l’indice della subResource. Alcuni buffer sono strutturati in maniera complessa. Ad esempio esistono Texture contenenti più copie di se stessa (mipmapping) o array di texture o altre combinazioni. Il buffer contiene quindi più parti e a seconda di quella scelta dovremo variare il parametro.

Vi lascio con un pò di consigli

• Nel caso di risorse dynamic, non effettuate il CopyResource su quest'ultimo. Le risorse dynamic possono essere scritte direttamente usando Map ed Unmap. Potete quindi bloccare la risorsa in Staging per leggere i dati ma usare il Map del buffer dinamico come destinazione. Questo farà risparmiare un bel pò di lavoro alla macchina
• Il processo di copia e soprattutto di Map ed Unmap sono eseguite in CPU, quindi non sono veloci quanto le altre operazione DirectX
• Per conoscere le caratteristiche dei buffer usate l'istruzione GetDesc
• Usate risorse Dynamic per buffer con frequenti scritture, Default per le risorse da mandare a video alla massima velocità possibile. Utilizzate Immutable solo per motivi di sicurezza (nel caso non vogliate modificare il contenuto da altre parti del codice)
• La copia tra risorse può avvenire solo tra buffer di pari dimensioni e formati (nel caso di texture)

Non rilascerò un esempio vista la semplicità dell'operazione