Limitazioni di accesso ai riquadri con mapping duplicati
In questa sezione vengono descritte le limitazioni di accesso ai riquadri con mapping duplicati.
Copia di risorse affiancate 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 sono state affiancate 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 i mapping vengono duplicati su una determinata superficie), i risultati dell'operazione di copia sui riquadri condivisi non sono definiti.
Copia in una risorsa affiancata con riquadri duplicati nell'area di destinazione
La copia in una risorsa affiancata con riquadri duplicati nell'area di destinazione produce risultati indefiniti in questi riquadri, a meno che i dati stessi non siano identici; riquadri diversi possono scrivere i riquadri in ordini diversi.
Accesso UAV ai mapping dei riquadri duplicati
Si supponga che una visualizzazione di accesso non ordinato (UAV) in una risorsa affiancata 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 alla memoria alle UAV in generale non è ordinato.
Rendering dopo la modifica del mapping dei riquadri o gli aggiornamenti del contenuto da mapping esterni
Se i mapping di riquadri di una risorsa affiancata sono stati modificati o il contenuto nei riquadri del pool affiancati è stato modificato tramite mapping di un'altra risorsa affiancata e il rendering della risorsa affiancata verrà eseguito tramite la visualizzazione di destinazione di rendering o la visualizzazione stencil profondità, l'applicazione deve cancellare (usando le API Cancella funzione fissa) o copiare completamente usando le API Copy*/Update* per i riquadri modificati all'interno dell'area di cui è stato eseguito il rendering (mappato o meno). L'errore di un'applicazione di cancellare o copiare in questi casi comporta strutture di ottimizzazione hardware per la visualizzazione di destinazione di rendering o la visualizzazione dello stencil di profondità non aggiornata 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.
L'operazione ID3D11DeviceContext1::ClearView supporta la cancellazione delle visualizzazioni di destinazione di rendering con rettangoli. Per l'hardware che supporta le risorse affiancate, ClearView deve supportare anche la cancellazione delle visualizzazioni stencil di profondità con rettangoli, per le superfici 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 delle aree in una risorsa affiancata in cui sono stati modificati i mapping, tale applicazione deve risolvere il requisito chiaro. L'applicazione può risolvere questo problema salvando prima il contenuto in cui i mapping dei riquadri sono stati modificati (copiandoli in una superficie temporanea, ad esempio, usando ID3D11DeviceContext2::CopyTiles), eseguendo il comando clear richiesto e quindi copiando nuovamente il contenuto. Anche se ciò comporta l'attività di mantenimento del contenuto della superficie per il rendering incrementale, lo svantaggio è che le prestazioni di rendering successive sulla superficie potrebbero risentire perché le ottimizzazioni del rendering potrebbero andare perse.
Se un riquadro viene mappato in più risorse affiancate contemporaneamente e il contenuto del riquadro viene modificato con qualsiasi mezzo (rendering, copia e così via) tramite una delle risorse affiancate, se lo stesso riquadro deve essere sottoposto a rendering tramite qualsiasi altra risorsa affiancata, 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 affiancata e che vengano mappati anche i riquadri del pool di riquadri a cui fa riferimento l'area di rendering dall'esterno dell'area di rendering (incluse le altre risorse affiancate, contemporaneamente o meno). Il rendering dei dati in questi riquadri non è garantito che vengano visualizzati correttamente quando vengono visualizzati tramite gli altri mapping, anche se il layout di memoria sottostante è compatibile. Questo fatto è dovuto a strutture di dati di ottimizzazione alcuni usi hardware che possono essere locali per 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 sottoposto a rendering tutti gli altri mapping alla stessa memoria a cui è possibile accedere (o cancellando tale memoria o copiando altri dati in esso 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 relativo contenuto e almeno il risparmio di memoria di avere un solo backup della memoria fisica rimane intatto. Inoltre, quando si passa da un'altra risorsa affiancata che condivide i mapping (a meno che non venga eseguita solo la lettura), è necessario chiamare l'API ID3D11DeviceContext2::TiledResourceBarrier tra i commutatori.
Rendering in riquadri condivisi all'interno dell'area di rendering
Se viene eseguito il rendering di un'area in una risorsa affiancata in e 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 affiancate che condividono i riquadri
Si supponga che più risorse affiancate 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 relative all'evitare problemi con le strutture di ottimizzazione hardware, le chiamate appropriate a ID3D11DeviceContext2::TiledResourceBarrier vengono effettuate e le risorse affiancate sono compatibili tra loro. Quest'ultimo è descritto qui in termini di ciò che significa per le risorse affiancate che condividono i riquadri in modo che non siano compatibili. Le condizioni di incompatibilità per l'accesso agli stessi dati nei mapping di riquadri duplicati sono l'uso di dimensioni o formati di superficie diverse o differenze nella presenza di flag di associazione di destinazione o profondità degli stencil di rendering 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 delle risorse vengono inizializzati per la prima volta con i nuovi dati (riciclando la memoria per uno scopo diverso), l'operazione di lettura o rendering successiva è corretta perché i dati non sanguinano tra interpretazioni incompatibili. Tuttavia, è necessario chiamare l'API TiledResourceBarrier quando si passa dall'accesso a mapping incompatibili come questo.
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, esistono molte meno restrizioni. Purché il formato e i tipi di superficie (ad esempio Texture2D) siano uguali, è possibile condividere i riquadri. Formati diversi compatibili sono casi come le superfici BC* e le dimensioni equivalenti a 32 bit o 16 bit per ogni formato di componente, ad esempio BC6H e R32G32B32A32. Molti formati a 32 bit per elemento possono essere associati anche a R32_* (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*); questa operazione è sempre stata consentita per le risorse non affiancate.
La condivisione tra riquadri compressi e non compressi va bene 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 di rendering o stencil di profondità, solo la memoria riempita con 0 può essere condivisa in modo sicuro; il mapping verrà visualizzato come qualsiasi decodifica da 0 a per la definizione del formato di risorsa specificato (in genere solo 0).
Argomenti correlati