Limitaciones de acceso de iconos con asignaciones duplicadas

Hay limitaciones en el acceso a iconos con asignaciones duplicadas, como al copiar recursos de streaming con origen y destino superpuestos, o al representar en iconos compartidos dentro del área de representación.

Copia de recursos de streaming con origen y destino superpuestos

Si los iconos del área de origen y destino de una operación Copy* tienen asignaciones duplicadas en el área de copia que se habrían superpuesto incluso si ambos recursos no fueran recursos de streaming y la operación Copy* admite copias superpuestas, la operación Copy* se comportará correctamente (como si el origen se copiase en una ubicación temporal antes de ir al destino). Pero si la superposición no es obvia (como los recursos de origen y destino son diferentes, pero las asignaciones o asignaciones de recursos compartidos se duplican en una superficie determinada), los resultados de la operación de copia en los iconos que se comparten no están definidos.

Copia al recurso de streaming con iconos duplicados en el área de destino

La copia en un recurso de streaming con iconos duplicados en el área de destino genera resultados indefinidos en estos iconos a menos que los datos en sí son idénticos; los iconos diferentes pueden escribir los iconos en diferentes pedidos.

UAV accede a asignaciones de iconos duplicadas

Supongamos que una vista de acceso sin ordenar (UAV) en un recurso de streaming tiene asignaciones de iconos duplicadas en su área o con otros recursos enlazados a la canalización. La ordenación de los accesos a estos iconos duplicados no está definida si se realiza mediante subprocesos diferentes, al igual que cualquier orden de acceso de memoria a los UAV en general no está ordenada.

Representación después de cambios de asignación de iconos o actualizaciones de contenido desde asignaciones externas

Si las asignaciones de iconos de un recurso de streaming han cambiado o el contenido de los iconos del grupo de mosaicos asignados han cambiado a través de las asignaciones de otro recurso de streaming y el recurso de streaming se va a representar a través de la vista de destino de representación o la vista de galería de símbolos de profundidad, la aplicación debe borrar (mediante la función fija Clear API) o copiar completamente con las API copy*/Update*, los iconos que han cambiado dentro del área que se está representando (asignado o no).

Si una aplicación borra o copia en estos casos, las estructuras de optimización de hardware para la vista de destino de representación dada o la vista de galería de símbolos de profundidad están obsoletas, y provocarán resultados de representación de elementos no utilizados en algunos hardware e incoherencia en diferentes hardware. Estas estructuras de datos de optimización ocultas usadas por el hardware podrían ser locales para asignaciones individuales y no visibles para otras asignaciones en la misma memoria.

Al borrar una vista de recursos (estableciendo todos los elementos de una vista de recursos en un valor), puede borrar las vistas de destino de representación con rectángulos. Para el hardware que admite recursos de streaming, borrar una vista de recursos también debe admitir la eliminación de vistas de galería de símbolos de profundidad con rectángulos, solo para superficies de profundidad (sin galería de símbolos). Esta operación permite a las aplicaciones borrar solo el área necesaria de una superficie.

Si una aplicación necesita conservar el contenido de memoria existente de las áreas de un recurso de streaming en el que las asignaciones han cambiado, esa aplicación debe solucionar el requisito claro. La aplicación puede realizar este trabajo en torno guardando primero el contenido en el que las asignaciones de iconos han cambiado (copiandolas en una superficie temporal), emitiendo el comando clear necesario y, a continuación, copiando el contenido de nuevo. Aunque esto lograría la tarea de conservar el contenido de la superficie para la representación incremental, el inconveniente es que el rendimiento posterior de la representación en la superficie podría sufrir porque las optimizaciones de representación podrían perderse.

Si un icono se asigna a varios recursos de streaming al mismo tiempo y el contenido del icono se manipula por cualquier medio (representación, copia, etc.) a través de uno de los recursos de streaming, si el mismo icono se va a representar a través de cualquier otro recurso de streaming, el icono debe borrarse primero como se describió anteriormente.

Representación en iconos compartidos fuera del área de representación

Supongamos que un área de un recurso de streaming se representa en y los iconos del grupo de iconos a los que hace referencia el área de representación también se asignan desde fuera del área de representación (incluido a través de otros recursos de streaming, al mismo tiempo o no). No se garantiza que los datos representados en estos iconos aparezcan correctamente cuando se ven a través de las otras asignaciones, aunque el diseño de memoria subyacente sea compatible. Este hecho se debe a las estructuras de datos de optimización que algunos usos de hardware pueden ser locales a asignaciones individuales para superficies representables y no visibles para otras asignaciones a la misma ubicación de memoria.

Puede solucionar esta restricción copiando de la asignación representada a todas las demás asignaciones a la misma memoria a la que se puede tener acceso (o borrando esa memoria o copiando otros datos en él si el contenido antiguo ya no es necesario). Aunque esta solución alternativa parece redundante, hace que todas las demás asignaciones a la misma memoria comprendan correctamente cómo acceder a su contenido y, al menos, el ahorro de memoria de tener solo una sola copia de seguridad de memoria física permanece intacta.

Además, al cambiar entre el uso de diferentes recursos de streaming que comparten asignaciones (a menos que solo lea), debe especificar una restricción de ordenación de acceso a datos (una barrera) entre varios recursos en mosaico, entre los modificadores.

Representación en iconos compartidos dentro del área de representación

Si un área de un recurso de streaming se representa en y dentro del área de representación se asignan varios iconos a la misma ubicación del grupo de iconos, los resultados de la representación no se definen en esos iconos.

Compatibilidad de datos entre iconos de uso compartido de recursos de streaming

Supongamos que varios recursos de streaming tienen asignaciones a las mismas ubicaciones del grupo de iconos y cada recurso se usa para acceder a los mismos datos. Este escenario solo es válido si se evitan los demás problemas con las estructuras de optimización de hardware, se especifican las barreras adecuadas (especificando una restricción de ordenación de acceso a datos entre varios recursos en mosaico) y los recursos de streaming son compatibles entre sí.

Este último se describe aquí en términos de lo que significa que los iconos de uso compartido de recursos de streaming sean incompatibles. Las condiciones de incompatibilidad de acceder a los mismos datos entre asignaciones de mosaicos duplicadas son el uso de diferentes dimensiones o formatos de superficie, o diferencias en la presencia de marcas de enlace de galería de símbolos de profundidad o destino de representación en los recursos. La escritura en la memoria con un tipo de asignación genera resultados indefinidos si posteriormente lee o representa a través de una asignación de un recurso incompatible.

Si las otras asignaciones de uso compartido de recursos se inicializan primero con nuevos datos (reciclando la memoria para un propósito diferente), la operación posterior de lectura o representación es correcta, ya que los datos no están sangrando entre interpretaciones incompatibles. Sin embargo, al cambiar entre el acceso a asignaciones incompatibles como esta, debe especificar barreras (especificando una restricción de ordenación de acceso a datos entre varios recursos en mosaico).

Si el destino de representación o la marca de enlace de galería de símbolos de profundidad no se establece en ninguna de las asignaciones de recursos que comparten entre sí, hay muchas menos restricciones. Siempre que los tipos de formato y superficie (por ejemplo, Texture2D) sean los mismos, se pueden compartir iconos. Los diferentes formatos que son compatibles son casos como superficies BC* y el tamaño equivalente de 32 bits o 16 bits por formato de componente, como BC6H y R32G32B32A32. Se pueden aplicar alias a muchos formatos de 32 bits por elemento* R32_* (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*); esta operación siempre se ha permitido para los recursos que no son de streaming.

El uso compartido entre mosaicos empaquetados y no empaquetados es correcto si los formatos son compatibles y los mosaicos se rellenan con color sólido.

Por último, si no hay nada común sobre las asignaciones de iconos de uso compartido de recursos, excepto que ninguna tiene marcas de enlace de galería de símbolos de profundidad o destino de representación, solo se puede compartir la memoria llena con 0 de forma segura; la asignación aparecerá como cualquier descodificación de 0 para la definición del formato de recurso especificado (normalmente solo 0).

Temas relacionados

Acceso de canalización a recursos de streaming