1

I'm researching options to offload D2D work from a render thread to a worker thread. The D2D worker thread would be used to generate textures (i.e., drawing to DXGI surface owned by the render thread's D3D context). The textures that get generated by D2D would eventually be rendered to a swap chain by a D3D context (D3D11) on the "render thread".

Because the D2D device is derived from the renderer's D3D device, it appears D2D will also use the D3D device's immediate context for issuing rendering commands. So simply moving the D2D work off of the render thread eventually leads to synchronization issues where the D3D context is being accessed from two threads simultaneously (the D2D worker thread and the render thread).

Are any of these ideas feasible?

  • Have D2D use a deferred D3D context, create a command list on a worker thread, and then merge this work back into the main rendering thread.
  • Generate D2D command lists on the worker thread and then play them back on the render thread. It's unclear to me if the command lists are intended to be used similar to the D3D command lists.

On a related note, one of the blurbs in the D2D docs is intriguing, but isn't explained well. 

You can have multiple device contexts, which can be helpful for improving performance in a threaded app. See Multithreaded Direct2D apps for more information.

Is there some sort of deferred D2D context that I'm missing here? The other page MSDN links to does not explain how "multiple D2D contexts" are used to help multithreading.

user8709
  • 1,342
  • 13
  • 31
  • "it appears D2D will also use the same D3D context" why is that? It may use the same DXGI device though (because we are passing it when creating D2D device by calling `ID2D1Factory1::CreateDevice`). – user7860670 Oct 14 '17 at 18:22
  • I think D2D is just using the device's immediate context when issuing it's drawing commands. I'd have to double check the debug layer error/callstack, but IIRC, using D2D from a worker thread led to simultaneous access happening on the immediate context. – user8709 Oct 14 '17 at 18:35
  • Have you checked the [Multithreaded Direct2D Apps article](https://msdn.microsoft.com/en-us/library/windows/desktop/jj569217(v=vs.85).aspx)? Especially the part about using `ID2D1Multithread` to sync access to underlying D3D resources. – user7860670 Oct 14 '17 at 18:51
  • 1
    Locking all accesses into the d3d renderer is an option, it's just extremely complicated to do correctly and seems like a maintenance nightmare! I was hoping for a more elegant solution, like issuing the d2d commands on a deferred context and then playing that back on the immediate. – user8709 Oct 14 '17 at 19:09

0 Answers0