Limitaciones de acceso de iconos con asignaciones duplicadas

  • Artículo

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 Copiar* admite copias superpuestas, la operación Copiar* 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 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 en un 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 propios datos son idénticos; Es posible que los iconos diferentes escriban los iconos en diferentes pedidos.

Acceso de UAV a asignaciones de iconos duplicados

Supongamos que una vista de acceso desordenada (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 por subprocesos diferentes, al igual que cualquier ordenación del acceso de memoria a los UAV en general no está ordenada.

Representación después de cambios en la 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 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 mediante las API copy*/Update*, los iconos que han cambiado dentro del área que se están representando (asignadas 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 determinada 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 algún hardware e incoherencia en diferentes hardware. Estas estructuras de datos de optimización ocultas usadas por el hardware pueden 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 desactivació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 á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 esta solución alternativa guardando primero el contenido en el que han cambiado las asignaciones de iconos (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, la desventaja 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 ha descrito 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 mosaicos a los que hace referencia el área de representación también se asignan desde fuera del área de representación (incluso 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 demás asignaciones, aunque el diseño de memoria subyacente sea compatible. Este hecho se debe a que las estructuras de datos de optimización usan algún uso de hardware que puede ser local para asignaciones individuales para superficies representables y no visibles para otras asignaciones en la misma ubicación de memoria.

Puede solucionar esta restricción copiando desde 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 ya no se necesita el contenido anterior). 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 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 en el á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 que cada recurso se usa para acceder a los mismos datos. Este escenario solo es válido si se evitan las demás reglas sobre cómo evitar 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 acceso a los mismos datos en las 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 no definidos si posteriormente lee o representa mediante una asignación de un recurso incompatible.

Si las demás 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 en 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 la marca de enlace de galería de símbolos de profundidad o destino de representación no está establecida en ninguna de las asignaciones de uso compartido de recursos entre sí, hay muchas menos restricciones. Siempre que el formato y los tipos de 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 con R32_* (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*); esta operación siempre se ha permitido para 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 nada es 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 rellenada 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).

Acceso de canalización a recursos de streaming