L'ordre dans lequel les interfaces COM Direct3D sont publiées est-il important?

Question

À titre d'exemple, considérons cette struct

struct Foo 
{ 
    ComPtr<ID3D11Texture2D> back_buffer; 
    ComPtr<IDXGISwapChain> swap_chain; 
    ComPtr<ID3D11DeviceContext> device_context; 
    ComPtr<ID3D11Device> device; 
} 

L'ordre de libération() appelle ici est le même que l'ordre dans lequel les objets COM ont été créés. Peut-il causer des problèmes?

Answer 1

En général, l'ordre de publication des objets COM n'est pas censé avoir d'importance. Cela dit, Direct3D n'utilise pas de règles COM strictes sur la durée de vie. Une fois que vous avez libéré la dernière référence à un périphérique Direct3D, tout ce qui est un objet enfant de ce périphérique n'est pas valide, quel que soit le nombre de références individuelles. Pour faciliter le nettoyage, il existe une 'détection de fuite d'objet' dans le périphérique de mise au point Direct3D. Il est donc utile de tout libérer avant de libérer l'instance de périphérique finale. Voir Direct3D SDK Debug Layer Tricks et DXGI Debug Device. Gardez à l'esprit que les références d'objet à objet peuvent également conserver les comptes en vie et que Direct3D utilise la «destruction différée». Par conséquent, une « sortie propre » nécessite une chasse d'eau après avoir dissociées les objets:

m_d3dContext->ClearState(); 
m_d3dContext->Flush(); 
// Release all your objects except the device 
// Final release of the device here 

Vous ne devez pas utiliser une telle & claire de rinçage pour le nettoyage avec Direct3D 11, mais vous finirez avec beaucoup de «faux rapports» d'objets en direct par le calque de débogage si vous n'avez pas Flush après la désolidarisation. Avec Direct3D 12, vous devez vous assurer que le GPU est inactif avant de commencer à libérer des choses pour obtenir une sortie propre.