Limitazioni di accesso ai riquadri con mappature duplicate.

Esistono limitazioni per l'accesso ai riquadri con mapping duplicati, ad esempio quando si copiano risorse di streaming con origine e destinazione sovrapposte o quando si esegue il rendering in riquadri condivisi all'interno dell'area di rendering.

Copia di risorse di streaming con origine e destinazione sovrapposte

Se i riquadri nell'area di origine e di destinazione di un'operazione Copia* hanno mapping duplicati nell'area di copia che si sovrappongono anche se entrambe le risorse non erano di streaming e l'operazione Copia* supporta copie sovrapposte, l'operazione Copia* si comporta correttamente (come se l'origine venga copiata in un percorso temporaneo prima di passare alla destinazione). Tuttavia, se la sovrapposizione non è ovvia (ad esempio le risorse di origine e di destinazione sono diverse, ma i mapping di condivisione o semplicemente i mapping vengono duplicati in una determinata superficie), i risultati dell'operazione di copia sui riquadri condivisi non sono definiti.

Copia nella risorsa di streaming con riquadri duplicati nell'area di destinazione

La copia in una risorsa di streaming con riquadri duplicati nell'area di destinazione produce risultati indefiniti in questi riquadri, a meno che i dati stessi non siano identici; i riquadri diversi potrebbero scrivere i riquadri in ordini diversi.

Accesso UAV ai mapping di riquadri duplicati

Si suppone che una visualizzazione di accesso non ordinata (UAV) in una risorsa di streaming abbia mapping di riquadri duplicati nell'area o con altre risorse associate alla pipeline. L'ordinamento degli accessi a questi riquadri duplicati non è definito se eseguito da thread diversi, così come qualsiasi ordinamento dell'accesso di memoria agli UAV in generale non è ordinato.

Rendering dopo modifiche al mapping dei riquadri o aggiornamenti del contenuto da mapping esterni

Se i mapping dei riquadri di una risorsa di streaming sono stati modificati o il contenuto nei riquadri del pool affiancati mappati è stato modificato tramite mapping di un'altra risorsa di streaming e il rendering della risorsa di streaming verrà eseguito tramite la visualizzazione di destinazione di rendering o la visualizzazione degli stencil profondità, l'applicazione deve eseguire Cancella (usando le API Cancella funzione fissa) o copiare completamente tramite le API Copia*/Aggiorna* i riquadri modificati all'interno dell'area di cui è stato eseguito il rendering (mappato o meno).

L'errore di un'applicazione per cancellare o copiare in questi casi comporta strutture di ottimizzazione hardware per la visualizzazione di destinazione di rendering o la visualizzazione degli stencil profondità non aggiornati e comporterà il garbage rendering dei risultati su alcuni hardware e incoerenze in hardware diverso. Queste strutture di dati di ottimizzazione nascoste usate dall'hardware potrebbero essere locali per singoli mapping e non visibili ad altri mapping alla stessa memoria.

Quando si cancella una visualizzazione risorse (impostando tutti gli elementi in una visualizzazione di risorse su un valore), è possibile cancellare le visualizzazioni di destinazione rendering con rettangoli. Per l'hardware che supporta le risorse di streaming, la cancellazione di una visualizzazione delle risorse deve supportare anche la cancellazione delle visualizzazioni relative agli stencil di profondità con rettangoli, per le superfici solo di profondità (senza stencil). Questa operazione consente alle applicazioni di cancellare solo l'area necessaria di una superficie.

Se un'applicazione deve mantenere il contenuto di memoria esistente di aree in una risorsa di streaming in cui sono stati modificati i mapping, tale applicazione deve aggirare il requisito chiaro. L'applicazione può eseguire questa operazione salvando prima il contenuto in cui i mapping dei riquadri sono stati modificati (copiandoli in una superficie temporanea), eseguendo il comando non crittografato richiesto e quindi copiando nuovamente il contenuto. Anche se ciò consente di mantenere il contenuto della superficie per il rendering incrementale, lo svantaggio è che le prestazioni di rendering successive sulla superficie potrebbero risentirne, in quanto le ottimizzazioni del rendering potrebbero essere perse.

Nel caso in cui un riquadro viene mappato in più risorse di streaming contemporaneamente e il contenuto dei riquadri viene modificato in qualsiasi modo (rendering, copia e così via) tramite una delle risorse di streaming, se il rendering dello stesso riquadro deve essere eseguito tramite qualsiasi altra risorsa di streaming, il riquadro deve essere cancellato prima come descritto in precedenza.

Rendering in riquadri condivisi all'esterno dell'area di rendering

Si supponga che venga eseguito il rendering di un'area in una risorsa di streaming e che i riquadri del pool di riquadri a cui fa riferimento l'area di rendering vengano mappati anche dall'esterno dell'area di rendering (incluse le altre risorse di streaming, contemporaneamente o meno). Non è garantito che il rendering dei dati in questi riquadri venga visualizzato correttamente quando viene visualizzato tramite gli altri mapping, anche se il layout di memoria sottostante è compatibile. Questo fatto è dovuto alle strutture dei dati di ottimizzazione, alcuni usi hardware che possono essere locali per i singoli mapping per le superfici di cui è possibile eseguire il rendering e non sono visibili ad altri mapping alla stessa posizione di memoria.

È possibile ovviare a questa restrizione copiando dal mapping renderizzato a tutti gli altri mapping alla stessa memoria a cui è possibile accedere (o cancellando tale memoria o copiando altri dati nella stessa memoria se il contenuto precedente non è più necessario). Anche se questo problema sembra ridondante, rende tutti gli altri mapping alla stessa memoria comprendere correttamente come accedere al contenuto e almeno il risparmio di memoria di avere un solo backup della memoria fisica rimane intatto.

Inoltre, quando si passa dall'uso di risorse di streaming diverse che condividono i mapping (a meno che non venga eseguita solo la lettura), è necessario specificare un vincolo di ordinamento di accesso ai dati (una barriera) tra più risorse affiancate, tra le opzioni.

Rendering in riquadri condivisi all'interno dell'area di rendering

Se si esegue il rendering di un'area in una risorsa di streaming e se all'interno dell'area di rendering, vengono mappati più riquadri alla stessa posizione del pool di riquadri, i risultati di rendering non sono definiti in tali riquadri.

Compatibilità dei dati tra le risorse di streaming che condividono i riquadri

Si supponga che più risorse di streaming abbiano mapping alle stesse posizioni del pool di riquadri e che ogni risorsa venga usata per accedere agli stessi dati. Questo scenario è valido solo se vengono evitate le altre regole per evitare problemi con le strutture di ottimizzazione hardware, vengono specificate barriere appropriate (specificando un vincolo di ordinamento di accesso ai dati tra più risorse affiancate) e le risorse di streaming sono compatibili tra loro.

Quest'ultimo è descritto qui in termini di ciò che significa che le risorse di streaming che condividono i riquadri non sono compatibili. Le condizioni di incompatibilità per l'accesso agli stessi dati attraverso mapping di riquadri duplicati sono l'uso di dimensioni o formati di superficie diversi, o differenze nella presenza di flag di rendering destinazione o di associazione dello stencil di proprietà sulle risorse. La scrittura nella memoria con un tipo di mapping produce risultati non definiti se successivamente si legge o si esegue il rendering tramite un mapping da una risorsa incompatibile.

Se gli altri mapping di condivisione risorse vengono inizializzati per la prima volta con nuovi dati (riciclando la memoria per uno scopo diverso), l'operazione di lettura o rendering successiva è corretta perché i dati non vengono scambiati tra interpretazioni incompatibili. Tuttavia, quando si passa dall'accesso a mapping incompatibili come questo, è necessario specificare le barriere (specificando un vincolo di ordinamento degli accessi ai dati tra risorse multiple).

Se la destinazione di rendering o il flag di associazione dello stencil di profondità non è impostato su nessuna delle risorse che condividono i mapping tra loro, ci sono molte meno restrizioni. A patto che il formato e i tipi di superficie (ad esempio Texture2D) siano gli stessi, i riquadri possono essere condivisi. I diversi formati compatibili sono casi come le superfici BC* e le dimensioni equivalenti di 32 bit o 16 bit per formato componente, ad esempio BC6H e R32G32B32A32. Molti formati di 32 bit per elemento possono essere associare a un alias anche con R32_* (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*); questa operazione è sempre stata consentita per le risorse non di streaming.

La condivisione tra riquadri compressi e non compressi è utile se i formati sono compatibili e i riquadri vengono riempiti con colore a tinta unita.

Infine, se nulla è comune sulle risorse che condividono i mapping dei riquadri, ad eccezione del fatto che nessuna ha flag di associazione di destinazione rendering o stencil profondità, solo la memoria riempita con 0 può essere condivisa in modo sicuro; il mapping verrà visualizzato come qualsiasi decodifica 0 per la definizione del formato di risorsa specificato (in genere solo 0).

Argomenti correlati

Accesso della pipeline alle risorse di streaming