Compressione a blocchi (Direct3D 10)
La compressione dei blocchi è una tecnica di compressione della trama per ridurre le dimensioni della trama. Rispetto a una trama con 32 bit per colore, una trama compressa a blocchi può essere fino al 75% più piccola. Le applicazioni visualizzano in genere un aumento delle prestazioni quando si usa la compressione a blocchi a causa del footprint di memoria più piccolo.
Durante la perdita, la compressione del blocco funziona bene ed è consigliata per tutte le trame che vengono trasformate e filtrate dalla pipeline. Le trame mappate direttamente allo schermo (elementi dell'interfaccia utente come icone e testo) non sono buone scelte per la compressione perché gli artefatti sono più evidenti.
Una trama compressa a blocchi deve essere creata come più dimensioni 4 in tutte le dimensioni e non può essere usata come output della pipeline.
- Come funziona la compressione dei blocchi?
- Uso della compressione dei blocchi
- Algoritmi di compressione
- Conversione del formato tramite Direct3D 10.1
- Argomenti correlati
Come funziona la compressione dei blocchi?
La compressione dei blocchi è una tecnica per ridurre la quantità di memoria necessaria per archiviare i dati dei colori. Archiviando alcuni colori nelle dimensioni originali e altri colori usando uno schema di codifica, è possibile ridurre notevolmente la quantità di memoria necessaria per archiviare l'immagine. Poiché l'hardware decodifica automaticamente i dati compressi, non vi è alcuna penalità per le prestazioni per l'uso di trame compresse.
Per vedere il funzionamento della compressione, vedere i due esempi seguenti. Il primo esempio descrive la quantità di memoria usata durante l'archiviazione di dati non compressi; il secondo esempio descrive la quantità di memoria usata durante l'archiviazione di dati compressi.
Archiviazione di dati non compressi
La figura seguente rappresenta una trama non compressa 4×4. Si supponga che ogni colore contenga un singolo componente colore (rosso ad esempio) e che sia archiviato in un byte di memoria.
I dati non compressi vengono disposti in memoria in modo sequenziale e richiedono 16 byte, come illustrato nella figura seguente.
Archiviazione di dati compressi
Dopo aver visto la quantità di memoria usata da un'immagine non compressa, esaminare la quantità di memoria salvata da un'immagine compressa. Il formato di compressione BC4 archivia 2 colori (1 byte ogni) e 16 indici a 3 bit (48 bit o 6 byte) usati per interpolare i colori originali nella trama, come illustrato nella figura seguente.
Lo spazio totale necessario per archiviare i dati compressi è di 8 byte, ovvero un risparmio di memoria del 50% nell'esempio non compresso. I risparmi sono ancora più grandi quando viene usato più di un componente di colore.
Il notevole risparmio di memoria fornito dalla compressione dei blocchi può causare un aumento delle prestazioni. Queste prestazioni sono a costo della qualità dell'immagine (a causa dell'interpolazione dei colori); tuttavia, la qualità inferiore spesso non è evidente.
La sezione successiva illustra come Direct3D 10 semplifica l'uso della compressione dei blocchi nell'applicazione.
Uso della compressione dei blocchi
Creare una trama compressa a blocchi esattamente come una trama non compressa (vedere Creare una trama da un file) tranne che si specifica un formato compresso a blocchi.
loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);
Creare quindi una vista per associare la trama alla pipeline. Poiché una trama compressa a blocchi può essere usata solo come input per una fase shader, si vuole creare una visualizzazione shader-resource chiamando CreateShaderResourceView.
Usare una trama compressa a blocchi allo stesso modo in cui si userebbe una trama non compressa. Se l'applicazione otterrà un puntatore alla memoria per bloccare i dati compressi, è necessario tenere conto della spaziatura interna della memoria in una mipmap che causa la differenza tra le dimensioni dichiarate e le dimensioni effettive.
Dimensioni virtuali e dimensioni fisiche
Se si dispone di codice dell'applicazione che usa un puntatore alla memoria per camminare la memoria di una trama compressa a blocchi, esiste una considerazione importante che può richiedere una modifica nel codice dell'applicazione. Una trama compressa a blocchi deve essere un multiplo di 4 in tutte le dimensioni perché gli algoritmi di compressione a blocchi operano su blocchi texel 4x4. Si tratta di un problema per una mappa mipmap le cui dimensioni iniziali sono divisibili da 4, ma i livelli suddivisi non sono. Il diagramma seguente mostra la differenza nell'area tra le dimensioni virtuali (dichiarate) e le dimensioni fisiche (effettive) di ogni livello di mipmap.
Il lato sinistro del diagramma mostra le dimensioni del livello mipmap generate per una trama non compressa di 60×40. Le dimensioni di primo livello vengono prese dalla chiamata API che genera la trama; ogni livello successivo è la metà delle dimensioni del livello precedente. Per una trama non compressa, non esiste alcuna differenza tra le dimensioni virtuali (dichiarate) e le dimensioni fisiche (effettive).
Il lato destro del diagramma mostra le dimensioni del livello mipmap generate per la stessa trama 60×40 con compressione. Si noti che sia i secondi che i terzi livelli hanno spaziatura della memoria per rendere i fattori di dimensioni di 4 su ogni livello. Ciò è necessario in modo che gli algoritmi possano funzionare su blocchi texel 4×4. Questo è evidente se si considerano livelli mipmap più piccoli di 4×4; le dimensioni di questi livelli di mipmap molto piccole verranno arrotondate fino al fattore più vicino di 4 quando la memoria della trama viene allocata.
L'hardware di campionamento usa le dimensioni virtuali; quando la trama viene campionata, il riempimento della memoria viene ignorato. Per i livelli di mipmap inferiori a 4×4, verranno usati solo i primi quattro texel per una mappa 2×2 e solo il primo texel verrà usato da un blocco 1×1. Tuttavia, non esiste alcuna struttura API che espone le dimensioni fisiche (incluso il riempimento della memoria).
In riepilogo, prestare attenzione all'uso di blocchi di memoria allineati durante la copia di aree contenenti dati compressi a blocchi. A tale scopo in un'applicazione che ottiene un puntatore alla memoria, assicurarsi che il puntatore usi il passo della superficie per tenere conto delle dimensioni della memoria fisica.
Algoritmi di compressione
Blocca le tecniche di compressione in Direct3D suddividere i dati di trama non compressi in 4×4 blocchi, comprimere ogni blocco e quindi archiviare i dati. Per questo motivo, le trame che devono essere compresse devono avere dimensioni di trama multiple di 4.
Il diagramma precedente mostra una trama partizionata in blocchi texel. Il primo blocco mostra il layout dei 16 texel etichettati a-p, ma ogni blocco ha la stessa organizzazione di dati.
Direct3D implementa diversi schemi di compressione, ognuno implementa un compromesso diverso tra il numero di componenti archiviati, il numero di bit per componente e la quantità di memoria utilizzata. Usare questa tabella per scegliere il formato ottimale con il tipo di dati e la risoluzione dei dati più adatta all'applicazione.
| Origine dati | Risoluzione della compressione dei dati (in bit) | Scegliere questo formato di compressione |
|---|---|---|
| Colore a tre componenti e alfa | Colore (5:6:5), Alfa (1) o nessun alfa | BC1 |
| Colore a tre componenti e alfa | Colore (5:6:5), Alfa (4) | RB2 |
| Colore a tre componenti e alfa | Colore (5:6:5), Alfa (8) | BC3 |
| Colore a un componente | Un componente (8) | BC4 |
| Colore a due componenti | Due componenti (8:8) | BC5 |
BC1
Usare il primo formato di compressione a blocchi (BC1) (DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM o DXGI_BC1_UNORM_SRGB) per archiviare dati di colore a tre componenti usando un colore 5:6:5 (rosso 5 bit, 6 bit verde, 5 bit blu). Questo vale anche se i dati contengono anche alfa a 1 bit. Presupponendo una trama 4×4 usando il formato dati più grande possibile, il formato BC1 riduce la memoria necessaria da 48 byte (16 colori × 3 componenti/colore × 1 byte/componente) a 8 byte di memoria.
L'algoritmo funziona su 4×4 blocchi di texel. Anziché archiviare 16 colori, l'algoritmo salva 2 colori di riferimento (color_0 e color_1) e indici di colore a 16 bit (blocchi a-p), come illustrato nel diagramma seguente.
Gli indici di colore (a-p) vengono usati per cercare i colori originali da una tabella di colori. La tabella colori contiene 4 colori. I primi due colori, color_0 e color_1, sono i colori minimi e massimi. Gli altri due colori, color_2 e color_3, sono colori intermedi calcolati con interpolazione lineare.
color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1
I quattro colori vengono assegnati valori di indice a 2 bit che verranno salvati in blocchi a-p.
color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11
Infine, ognuno dei colori in blocchi a-p viene confrontato con i quattro colori della tabella colori e l'indice per il colore più vicino viene archiviato nei blocchi a 2 bit.
Questo algoritmo si presta anche ai dati contenenti alfa a 1 bit. L'unica differenza è che color_3 è impostato su 0 (che rappresenta un colore trasparente) e color_2 è una miscela lineare di color_0 e color_1.
color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;
Differenze tra Direct3D 9 e Direct3D 10:
Questo formato esiste sia in Direct3D 9 che in 10.
- In Direct3D 9 il formato BC1 viene chiamato D3DFMT_DXT1.
- In Direct3D 10 il formato BC1 è rappresentato da DXGI_FORMAT_BC1_UNORM o DXGI_FORMAT_BC1_UNORM_SRGB.
RB2
Usare il formato BC2 (DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM o DXGI_BC2_UNORM_SRGB) per archiviare i dati contenenti dati di colore e alfa con bassa coerenza (usare BC3 per dati alfa altamente coerenti). Il formato BC2 archivia i dati RGB come colore 5:6:5 (5 bit rossi, 6 bit verdi, 5 bit blu) e alfa come valore separato a 4 bit. Presupponendo una trama 4×4 usando il formato dati più grande possibile, questa tecnica di compressione riduce la memoria necessaria da 64 byte (16 colori × 4 componenti/colore × 1 byte/componente) a 16 byte di memoria.
Il formato BC2 archivia i colori con lo stesso numero di bit e layout di dati del formato BC1 ; tuttavia, BC2 richiede un ulteriore 64 bit di memoria per archiviare i dati alfa, come illustrato nel diagramma seguente.
Differenze tra Direct3D 9 e Direct3D 10:
Questo formato esiste sia in Direct3D 9 che in 10.
In Direct3D 9 il formato BC2 viene chiamato D3DFMT_DXT2 e D3DFMT_DXT3.
In Direct3D 10 il formato BC2 è rappresentato da DXGI_FORMAT_BC2_UNORM o DXGI_FORMAT_BC2_UNORM_SRGB
BC3
Usare il formato BC3 (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM o DXGI_BC3_UNORM_SRGB) per archiviare dati di colore altamente coerenti (usare BC2 con dati alfa meno coerenti). Il formato BC3 archivia i dati di colore usando 5:6:5 colore (5 bit rossi, 6 bit verdi, 5 bit blu) e dati alfa usando un byte. Presupponendo una trama 4×4 usando il formato dati più grande possibile, questa tecnica di compressione riduce la memoria necessaria da 64 byte (16 colori × 4 componenti/colore × 1 byte/componente) a 16 byte di memoria.
Il formato BC3 archivia i colori con lo stesso numero di bit e layout di dati del formato BC1 ; Tuttavia, BC3 richiede un ulteriore 64 bit di memoria per archiviare i dati alfa. Il formato BC3 gestisce alfa archiviando due valori di riferimento e interpolando tra di essi (analogamente al modo in cui BC1 archivia il colore RGB).
L'algoritmo funziona su 4×4 blocchi di texel. Anziché archiviare 16 valori alfa, l'algoritmo archivia 2 alfa di riferimento (alpha_0 e alpha_1) e indici di colore a 16 bit (alfa a through p), come illustrato nel diagramma seguente.
Il formato BC3 usa gli indici alfa (a-p) per cercare i colori originali da una tabella di ricerca contenente 8 valori. I primi due valori, alpha_0 e alpha_1, sono i valori minimi e massimi; gli altri sei valori intermedi vengono calcolati usando l'interpolazione lineare.
L'algoritmo determina il numero di valori alfa interpolati esaminando i due valori alfa di riferimento. Se alpha_0 è maggiore di alpha_1, BC3 interpola 6 valori alfa; in caso contrario, interpola 4. Quando BC3 interpola solo 4 valori alfa, imposta due valori alfa aggiuntivi (0 per completamente trasparente e 255 per completamente opaco). BC3 comprime i valori alfa nell'area 4×4 texel archiviando il codice bit corrispondente ai valori alfa interpolati che corrispondono più strettamente all'alfa originale per un determinato texel.
if( alpha_0 > alpha_1 )
{
// 6 interpolated alpha values.
alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010
alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011
alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100
alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101
alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110
alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111
}
else
{
// 4 interpolated alpha values.
alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010
alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011
alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100
alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101
alpha_6 = 0; // bit code 110
alpha_7 = 255; // bit code 111
}
Differenze tra Direct3D 9 e Direct3D 10:
In Direct3D 9 il formato BC3 viene chiamato D3DFMT_DXT4 e D3DFMT_DXT5.
In Direct3D 10 il formato BC3 è rappresentato da DXGI_FORMAT_BC3_UNORM o DXGI_FORMAT_BC3_UNORM_SRGB.
BC4
Usare il formato BC4 per archiviare i dati di colore a un componente usando 8 bit per ogni colore. A causa dell'accuratezza maggiore (rispetto a BC1), BC4 è ideale per archiviare i dati a virgola mobile nell'intervallo di [0 a 1] usando il formato di DXGI_FORMAT_BC4_UNORM e [-1 a +1] usando il formato DXGI_FORMAT_BC4_SNORM. Supponendo una trama di 4×4 usando il formato dati più grande possibile, questa tecnica di compressione riduce la memoria necessaria da 16 byte (16 colori × 1 componenti/colore × 1 byte/componente) a 8 byte.
L'algoritmo funziona su 4×4 blocchi di texel. Invece di archiviare 16 colori, l'algoritmo archivia 2 colori di riferimento (red_0 e red_1) e indici di colore a 16 bit (rosso a forma di p rossa), come illustrato nel diagramma seguente.
L'algoritmo usa gli indici a 3 bit per cercare i colori da una tabella colori contenente 8 colori. I primi due colori, red_0 e red_1, sono i colori minimi e massimi. L'algoritmo calcola i colori rimanenti usando l'interpolazione lineare.
L'algoritmo determina il numero di valori di colore interpolati esaminando i due valori di riferimento. Se red_0 è maggiore di red_1, BC4 interpola 6 valori di colore; in caso contrario, interpola 4. Quando BC4 interpola solo 4 valori di colore, imposta due valori di colore aggiuntivi (0,0f per completamente trasparente e 1,0f per completamente opaco). BC4 comprime i valori alfa nell'area 4×4 texel archiviando il codice bit corrispondente ai valori alfa interpolati che corrispondono più strettamente all'alfa originale per un determinato texel.
BC4_UNORM
L'interpolazione dei dati a componente singolo viene eseguita come nell'esempio di codice seguente.
unsigned word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = 0.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
I colori di riferimento vengono assegnati indici a 3 bit (000-111 poiché sono presenti 8 valori), che verranno salvati in blocchi rossi in un p rosso durante la compressione.
BC4_SNORM
La DXGI_FORMAT_BC4_SNORM è esattamente la stessa, ad eccezione del fatto che i dati vengono codificati nell'intervallo SNORM e quando vengono interpolati 4 valori di colore. L'interpolazione dei dati a componente singolo viene eseguita come nell'esempio di codice seguente.
signed word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = -1.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
I colori di riferimento vengono assegnati indici a 3 bit (000-111 poiché sono presenti 8 valori), che verranno salvati in blocchi rossi in un p rosso durante la compressione.
BC5
Usare il formato BC5 per archiviare i dati di colore a due componenti usando 8 bit per ogni colore. Come risultato dell'accuratezza maggiore (rispetto a BC1), BC5 è ideale per archiviare i dati a virgola mobile nell'intervallo di [0 a 1] usando il formato di DXGI_FORMAT_BC5_UNORM e [-1 a +1] usando il formato DXGI_FORMAT_BC5_SNORM. Presupponendo una trama di 4×4 usando il formato dati più grande possibile, questa tecnica di compressione riduce la memoria necessaria da 32 byte (16 colori × 2 componenti/colore × 1 byte/componente) a 16 byte.
L'algoritmo funziona su 4×4 blocchi di texel. Anziché archiviare 16 colori per entrambi i componenti, l'algoritmo archivia 2 colori di riferimento per ogni componente (red_0, red_1, green_0 e green_1) e 16 indici di colore a 3 bit per ogni componente (rosso un tramite p rosso e verde un tramite p verde), come illustrato nel diagramma seguente.
L'algoritmo usa gli indici a 3 bit per cercare i colori da una tabella colori contenente 8 colori. I primi due colori, red_0 e red_1 (o green_0 e green_1) sono i colori minimi e massimi. L'algoritmo calcola i colori rimanenti usando l'interpolazione lineare.
L'algoritmo determina il numero di valori di colore interpolati esaminando i due valori di riferimento. Se red_0 è maggiore di red_1, BC5 interpola 6 valori di colore; in caso contrario, interpola 4. Quando BC5 interpola solo 4 valori di colore, imposta i due valori di colore rimanenti a 0,0f e 1.0f.
BC5_UNORM
L'interpolazione dei dati a componente singolo viene eseguita come nell'esempio di codice seguente. I calcoli per i componenti verdi sono simili.
unsigned word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = 0.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
I colori di riferimento vengono assegnati indici a 3 bit (000-111 poiché sono presenti 8 valori), che verranno salvati in blocchi rossi in un p rosso durante la compressione.
BC5_SNORM
Il DXGI_FORMAT_BC5_SNORM è esattamente lo stesso, ad eccezione del fatto che i dati vengono codificati nell'intervallo SNORM e quando vengono interpolati 4 valori di dati, i due valori aggiuntivi sono -1.0f e 1.0f. L'interpolazione dei dati a componente singolo viene eseguita come nell'esempio di codice seguente. I calcoli per i componenti verdi sono simili.
signed word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = -1.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
I colori di riferimento vengono assegnati indici a 3 bit (000-111 poiché sono presenti 8 valori), che verranno salvati in blocchi rossi in un p rosso durante la compressione.
Conversione del formato tramite Direct3D 10.1
Direct3D 10.1 consente copie tra trame prestrutturate e trame compresse a blocchi della stessa larghezza di bit. Le funzioni che possono eseguire questa operazione sono CopyResource e CopySubresourceRegion.
A partire da Direct3D 10.1, è possibile usare CopyResource e CopySubresourceRegion per copiare tra alcuni tipi di formato. Questo tipo di operazione di copia esegue un tipo di conversione di formato che reinterpreta i dati delle risorse come tipo di formato diverso. Si consideri questo esempio che mostra la differenza tra la reinterpretazione dei dati con il modo in cui si comporta un tipo più tipico di conversione:
FLOAT32 f = 1.0f;
UINT32 u;
Per reinterpretare 'f' come tipo di 'u', usare memcpy:
memcpy( &u, &f, sizeof( f ) ); // ‘u’ becomes equal to 0x3F800000.
Nella reinterpretazione precedente il valore sottostante dei dati non cambia; memcpy reinterpreta il float come intero senza segno.
Per eseguire il tipo più tipico di conversione, usare l'assegnazione:
u = f; // ‘u’ becomes 1.
Nella conversione precedente il valore sottostante dei dati cambia.
Nella tabella seguente sono elencati i formati di origine e destinazione consentiti che è possibile usare in questo tipo di conversione del formato di reinterpretazione. È necessario codificare correttamente i valori per il funzionamento della reinterpretazione come previsto.
| Larghezza bit | Risorsa non compressa | risorsa Block-Compressed |
|---|---|---|
| 32 | DXGI_FORMAT_R32_UINT DXGI_FORMAT_R32_SINT |
DXGI_FORMAT_R9G9B9E5_SHAREDEXP |
| 64 | DXGI_FORMAT_R16G16B16A16_UINT DXGI_FORMAT_R16G16B16A16_SINT DXGI_FORMAT_R32G32_UINT DXGI_FORMAT_R32G32_SINT |
DXGI_FORMAT_BC1_UNORM[_SRGB] DXGI_FORMAT_BC4_UNORM DXGI_FORMAT_BC4_SNORM |
| 128 | DXGI_FORMAT_R32G32B32A32_UINT DXGI_FORMAT_R32G32B32A32_SINT |
DXGI_FORMAT_BC2_UNORM[_SRGB] DXGI_FORMAT_BC3_UNORM[_SRGB] DXGI_FORMAT_BC5_UNORM DXGI_FORMAT_BC5_SNORM |
Argomenti correlati
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per