2017-05-15 3 views
0

J'ai une texture DX11 partagée qui est utilisée avec 2 périphériques différents dans des threads séparés.DX11 Mise à jour des textures partagées

Thread1 (fonctionnement sur l'appareil 1): Appelée chaque image et met à jour la texture partagée

Thread2 (opérant sur DEVICE2): Consomme la texture partagée en copiant à une autre texture. La fréquence est beaucoup plus faible que le thread 1.

Selon MSDN «Si une texture partagée est mise à jour sur un périphérique, ID3D11DeviceContext :: Flush doit être appelé sur ce périphérique. Cependant, appeler le flush sur le thread1 chaque image est très cher et nous voyons un énorme succès de performance. Nous ne pouvons pas vider le périphérique 1 sur le thread 2, car un contexte de périphérique n'est pas thread-safe.

Existe-t-il un moyen de rendre la mise à jour de texture partagée efficace lorsque les threads 2 doivent la consommer?

Merci pour votre aide! MSDN n'est pas très utile lorsqu'il s'agit de textures partagées. souligné texte

Répondre

0

Pour synchroniser l'accès à la ressource partagée entre deux threads (ou) interprocessus vous pouvez utiliser IDXGIKeyedMutex. Il est décrit ici en détails: https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx#dxgi_1.1_synchronized_shared_surfaces

Vous pouvez vérifier l'exemple de code fourni, bien qu'ils ne montrent que le partage de ressources entre deux périphériques DX10. C'est la même chose pour les appareils DX11. La partie essentielle est de QueryInterface d'abord la texture partagée pour IDXGIResource, puis pour IDXGIKeyedMutex. Après cela, vous utilisez le mutex pour la synchronisation en utilisant les fonctions AcquireSync et ReleaseSync.

+0

Malheureusement, les mutex à clé ne fonctionnent pas pour moi car il n'y a pas d'ordre défini pour lequel le thread doit s'exécuter en premier. Les deux threads peuvent être appelés à des intervalles aléatoires, ce qui rend les mutex à clé inadaptés à ce scénario – Sid