Necessità di risorse di streaming

Le risorse di streaming sono necessarie in modo che la memoria GPU non rifiuti l'archiviazione delle aree di superfici a cui non si accede e per indicare all'hardware come filtrare i riquadri adiacenti.

Streaming di risorse o texture di tipo sparse

Le risorse di streaming, denominate risorse affiancate in Direct3D 11, sono risorse logiche di grandi dimensioni che usano minuscole quantità di memoria fisica.

Un altro nome per le risorse di streaming è costituito da texture di tipo sparse. "Sparse" indica sia la natura a riquadri delle risorse, sia probabilmente la ragione principale per cui sono a forma di riquadro: non tutte devono essere mappate contemporaneamente. Infatti, un'applicazione potrebbe creare in modo intenzionale una risorsa di streaming in cui non vengono creati dati per tutte le aree e le mip della risorsa, in via intenzionale. Quindi, il contenuto stesso potrebbe essere di tipo sparse e il mapping del contenuto nella memoria gpu (Graphics Processing Unit) in un determinato momento sarebbe un sottoinsieme di questo (ancora più sparse).

Senza affiancamento, le allocazioni di memoria vengono gestite con granularità di sottorisorsa

In un sistema grafico (ovvero il sistema operativo, il driver di visualizzazione e l'hardware grafico) senza il supporto delle risorse di streaming, il sistema grafico gestisce tutte le allocazioni di memoria Direct3D a livello di granularità di sottorisorsa.

Per un buffer, l'intero buffer è la sottorisorsa.

Per una Texture, (ad esempio, Texture2D), ogni livello mip è una sottorisorsa. Per una matrice di texture, ad esempio Texture2DArray) ciascun livello mip in una determinata sezione di matrice è una sottorisorsa. Il sistema grafico espone solo la possibilità di gestire il mapping delle allocazioni a questa granularità di sottorisorsa. Nel contesto delle risorse di streaming, il "mapping" si riferisce alla visualizzazione dei dati nella GPU.

Senza affiancamento, non può accedere solo a una piccola parte della catena mipmap

Si supponga che un'applicazione sia a conoscenza del fatto che un'operazione di rendering specifica deve accedere solo a una piccola parte di una catena mipmap dell'immagine (forse non anche all'intera area di una mipmap specificata). Idealmente, l'app potrebbe informare il sistema grafico su questa esigenza. Il sistema grafico si preoccupa quindi solo di assicurarsi che la memoria necessaria sia mappata sulla GPU senza paging in memoria eccessiva.

In realtà, senza il supporto delle risorse di streaming, il sistema grafico può essere informato solo sulla memoria di cui è necessario eseguire il mapping sulla GPU alla granularità della sottorisorsa ( ad esempio, una gamma di livelli mipmap completi a cui è possibile accedere). Non c'è alcuna richiesta di errore nel sistema grafico, quindi potenzialmente è necessario usare un sacco di memoria GPU in eccesso per eseguire il mapping completo delle sottorisorse prima che venga eseguito un comando di rendering che fa riferimento a qualsiasi parte della memoria. Questo è solo un problema che rende difficile l'uso di allocazioni di memoria di grandi dimensioni in Direct3D senza il supporto delle risorse di streaming.

Paging software per suddividere la superficie in riquadri più piccoli

Il paging software può essere usato per suddividere la superficie in riquadri di dimensioni sufficienti per gestire l'hardware.

Direct3D supporta superfici Texture2D con un massimo di 16384 pixel su un determinato lato. Un'immagine di 16384 pixel di larghezza per 16384 di altezza e 4 byte per pixel consumerebbe 1 GB di memoria video (e l'aggiunta di mipmap raddoppierebbe questa quantità). In pratica, è necessario fare riferimento a tutti i 1 GB in una singola operazione di rendering.

Alcuni sviluppatori di giochi modellano le superfici del terreno fino a 128K di 128K. Il modo in cui ottengono questo per lavorare su GPU esistenti consiste nel suddividere la superficie in riquadri abbastanza piccoli per gestire l'hardware. L'applicazione deve stabilire quali riquadri potrebbero essere necessari e caricarli in una cache di texture nella GPU, ovvero, un sistema di paging software.

Un aspetto negativo significativo di questo approccio deriva dall'hardware che non conosce nulla sul paging che sta avvenendo: quando una parte di un'immagine deve essere visualizzata sullo schermo che si trova a cavallo tra i riquadri, l'hardware non sa come eseguire il filtro a funzione fissa (ovvero efficiente) tra i riquadri. Ciò significa che l'applicazione che gestisce il proprio affiancamento software deve ricorrere al filtro manuale delle texture nel codice shader (che diventa molto costoso se si desidera un filtro anisotropico di buona qualità) e/o sprecare la memoria creando squadri che contengono dati dai riquadri adiacenti in modo che il filtro hardware a funzione fissa possa continuare a fornire assistenza.

Rendere la rappresentazione a riquadri dell'allocazione delle superfici una caratteristica di prima classe

Se una rappresentazione affiancata delle allocazioni di superficie è una funzionalità di prima classe nel sistema grafico, l'applicazione potrebbe indicare all'hardware quali riquadri rendere disponibili. In questo modo, viene sprecata meno memoria GPU archiviando aree di superfici a cui l'applicazione sa che non si accederà, e l'hardware può comprende come eseguire il filtraggio tra riquadri adiacenti, alleviando alcune delle difficoltà incontrate dagli sviluppatori che eseguono l'affiancamento software in autonomia.

Tuttavia, per fornire una soluzione completa, è necessario fare qualcosa per gestire il fatto che, indipendentemente dal fatto che l'affiancamento all'interno di una superficie sia supportato, la dimensione massima della superficie è attualmente 16384 - nessuna parte vicino agli 128K+ già desiderate dalle applicazioni. Richiedere semplicemente l'hardware per supportare dimensioni di texture più grandi è già un approccio, tuttavia vi sono costi significativi e/o compromessi per dirigersi in questo percorso.

Il percorso del filtro delle texture e il percorso di rendering di Direct3D sono già saturi in termini di precisione per supportare texture da 16.000 con gli altri requisiti, ad esempio supportando estensioni del riquadro di visualizzazione che cadono dalla superficie durante il rendering o supportano il wrapping della texture al di fuori del bordo della superficie durante il processo di filtraggio. È possibile definire un compromesso in base al quale, se la dimensione della texture aumenta oltre i 16K, si rinuncia in qualche modo alla funzionalità/precisione. Anche con questa concessione, tuttavia, potrebbero essere necessari costi hardware aggiuntivi in termini di capacità di indirizzamento in tutto il sistema hardware per passare a dimensioni di texture maggiori.

Problema con texture di grandi dimensioni: precisione per le posizioni sulla superficie

Un problema che entra in gioco quando le texture diventano molto grandi è che le coordinate delle texture a virgola mobile con precisione singola (e gli interpolatori associati per supportare la rasterizzazione) esauriscono la precisione per specificare accuratamente le posizioni sulla superficie. Seguirebbe poi l'applicazione di filtri delle trame in jittery Un'opzione costosa sarebbe quella di richiedere il supporto dell'interpolatore a precisione doppia, anche se potrebbe essere eccessiva se si dispone di un'alternativa ragionevole.

Abilitazione di più risorse di dimensioni diverse per condividere la memoria

Un altro scenario che può essere gestito dalle risorse di streaming consiste nell'abilitare più risorse di dimensioni/formati diversi per condividere la stessa memoria. In alcuni casi le applicazioni hanno set esclusivi di risorse che non vengono usate contemporaneamente o risorse create solo per uso molto breve e quindi eliminate, seguite dalla creazione di altre risorse. Una forma di generalità che può derivare dalle "risorse di streaming" è la possibilità di consentire all'utente di puntare più risorse diverse alla stessa memoria (sovrapposta). In altre parole, la creazione e la distruzione di "risorse" (che definiscono una dimensione/un formato e così via) possono essere separati dalla gestione della memoria sottostante le risorse dal punto di vista dell'applicazione.

Argomenti correlati

Risorse di streaming