I mapping si trovano in un pool di riquadri

Quando viene creata una risorsa con il flag D3D11_RESOURCE_MISC_TILED, i riquadri che costituiscono la risorsa provengono da posizioni in un pool di riquadri. Un pool di riquadri è un pool di memoria (supportato da una o più allocazioni dietro le quinte, senza visualizzare l'applicazione). Il sistema operativo e il driver di visualizzazione gestiscono questo pool di memoria e il footprint di memoria è facilmente comprensibile da un'applicazione. Le risorse affiancate mappano le aree di 64 KB puntando alle posizioni in un pool di riquadri. Un fallout di questa configurazione è che consente a più risorse di condividere e riutilizzare gli stessi riquadri e anche per riutilizzare gli stessi riquadri in posizioni diverse all'interno di una risorsa, se necessario.

Il costo per la flessibilità di popolare i riquadri per una risorsa da un pool di riquadri è che la risorsa deve eseguire il lavoro di definizione e gestione del mapping dei riquadri nel pool di riquadri rappresentano i riquadri necessari per la risorsa. È possibile modificare i mapping dei riquadri. Inoltre, non tutti i riquadri in una risorsa devono essere mappati alla volta; una risorsa può avere mapping di NULL. Un mapping di NULL definisce un riquadro che non è disponibile dal punto di vista della risorsa che vi accede.

È possibile creare più pool di riquadri e qualsiasi numero di risorse affiancate può essere mappato contemporaneamente a qualsiasi pool di riquadri specificato. I pool di riquadri possono anche essere cresciuti o compattati. Per altre info, vedi ridimensionamento pool di riquadri. Un vincolo esistente per semplificare l'implementazione del driver di visualizzazione e del runtime consiste nel fatto che una determinata risorsa affiancata può avere mapping solo al massimo un pool di riquadri alla volta (anziché eseguire il mapping simultaneo a più pool di riquadri).

La quantità di spazio di archiviazione associato a una risorsa affiancata stessa (ovvero, la memoria indipendente del pool di riquadri) è approssimativamente proporzionale al numero di riquadri effettivamente mappati al pool in qualsiasi momento. Nell'hardware, questo fatto riduce il ridimensionamento del footprint di memoria per l'archiviazione tabelle di pagine con la quantità di riquadri mappati (ad esempio, usando uno schema di tabella di pagine multilivello in base alle esigenze).

Il pool di riquadri può essere considerato come un'astrazione interamente software che consente alle applicazioni Direct3D di essere in grado di programmare efficacemente le tabelle di pagine nell'unità di elaborazione grafica (GPU) senza dover conoscere direttamente i dettagli di implementazione di basso livello (o gestire direttamente gli indirizzi del puntatore). I pool di riquadri non applicano livelli aggiuntivi di riferimento indiretto nell'hardware. Le ottimizzazioni di una tabella di pagina a livello singolo che usano costrutti come le directory di pagine sono indipendenti dal concetto di pool di riquadri.

Si esaminerà l'archiviazione che la tabella di pagine stessa potrebbe richiedere nel peggiore dei casi(anche se in pratica le implementazioni richiedono solo l'archiviazione approssimativamente proporzionale a ciò che viene mappato).

Si supponga che ogni voce della tabella di pagina sia a 64 bit.

Per le dimensioni peggiori della tabella delle pagine per una singola superficie, in base ai limiti delle risorse in Direct3D 11, si supponga che una risorsa affiancata venga creata con un formato a 128 bit per elemento (ad esempio, un float RGBA), quindi un riquadro di 64 KB contiene solo 4096 pixel. La dimensione massima supportata Texture2DArray di 16384*16384*2048 (ma con un solo mipmap) richiederebbe circa 1 GB di spazio di archiviazione nella tabella della pagina se completamente popolato (non inclusi mipmap) usando voci di tabella a 64 bit. L'aggiunta di mipmap aumenta l'archiviazione delle tabelle di pagine completamente mappata (peggiore del caso) di circa un terzo, a circa 1,3 GB.

Questo caso consente di accedere a circa 10,6 terabyte di memoria indirizzabile. Potrebbe esserci un limite alla quantità di memoria indirizzabile, che potrebbe ridurre questi importi, forse intorno all'intervallo di terabyte.

Un altro caso da considerare è un singolo Texture2D risorsa affiancata di 16384*16384 con un formato a 32 bit per elemento, inclusi mipmap. Lo spazio necessario in una tabella di pagine completamente popolata sarebbe di circa 170 KB con voci di tabella a 64 bit.

Si consideri infine un esempio che usa un formato BC, ad esempio BC7 con 128 bit per riquadro di 4x4 pixel. Questo è un byte per pixel. Un Texture2DArray di 16384*16384*2048, incluse le mipmap, richiederebbe circa 85 MB per popolare completamente questa memoria in una tabella di pagine. Ciò non è negativo considerando questo consente a una risorsa affiancata di estendersi su 550 gigapixel (512 GB di memoria in questo caso).

In pratica, in nessun punto vicino a questi mapping completi sarebbe stato definito dato che la quantità di memoria fisica disponibile non permetterebbe in nessuna posizione vicina a quella molto di essere mappata e a cui si fa riferimento alla volta. Tuttavia, con un pool di riquadri, le applicazioni potrebbero scegliere di riutilizzare i riquadri (ad esempio, riutilizzando un riquadro colorato "nero" per aree nere di grandi dimensioni in un'immagine), usando in modo efficace il pool di riquadri (ovvero i mapping delle tabelle di pagine) come strumento per la compressione della memoria.

Il contenuto iniziale della tabella di pagina è NULL per tutte le voci. Le applicazioni non possono anche passare i dati iniziali per il contenuto della memoria della superficie perché inizia senza backup della memoria.

In questa sezione

Argomenti correlati

Creazione di risorse affiancate