IDXGISurface1 thread / sync security rules for GetDC / ReleaseDC?

What are the thread safety rules for IDXGISurface1 GetDC/ReleaseDC for textures created using D3D11_RESOURCE_MISC_GDI_COMPATIBLE ?

Can I interact with ID3D11Device and ID3D11DeviceContext between GetDC and ReleaseDC in another thread, without data calculations or blocking due to implicit synchronization? Or I don’t want the idle GPU to create a separate D3D11Device for the stream rendering the GDI and then passing it back to the β€œmain” D3D11Device by copying to D3D11_RESOURCE_MISC_SHARED_KEYED_MUTEX ?

i.e. is valid?

 thread 1: D3D11Device::CreateTexture2D // Create texture 1 IDXGISurface1::GetDC // Get DC for texture 1 ... // Draw to texture1 using GDI IDXGISurtface1::ReleaseDC // Release DC for texture1 thread 2: // Is this valid if thread 1 is drawing using GDI? D3D11DeviceContext::OMSetRenderTargets D3D11DeviceContext::Draw // Draw texture2. 
+7
source share
1 answer

The following two points with MSDN seem to suggest that this stream is not only unsafe, but also shortened when the HDC is outstanding.

  • You must free the device (they are HDC related) and call the IDXGISurface1 :: ReleaseDC method before you make any new Direct3D commands.

  • This method fails if an excellent DC has already been created using this method.

Getting HDC from DXGISurface inherently includes a superficial parent D3D11 DC. Multi-threaded access to the DC D3D11 is also not supported. From this MSDN page: if multiple threads must access the same ID3D11DeviceContext, they must use some kind of synchronization mechanism, such as critical sections, to synchronize access to this ID3D11DeviceContext.

I would try to prepare a GDI drawing on a separate thread, as you said, but put it in the system memory buffer. Then simply rinse the contents onto the surface of the DXGI.

Also note that most of these topics are related to immediate context behavior, D3D11 Delayed context may have different behavior.

+1
source

All Articles