Multi-threading with multiple D3D devices

[abucur]

Hello!

The use case is to support rendering in multiple threads completely isolated from each other. No shared resources, contexts and so on (more exactly, there can be many isolated windows, each with its own SwapChainPanel)

After looking a bit in the code it seems that multi-threaded rendering "should" be possible if each thread gets its own D3D device. From a very high level this seems to reduce the amount of data shared by the threads to a minimum and it makes the use case mentioned above possible to implement without serializing everything on a single thread.

1. Is this approach feasible? If not, where is synchronization required when each thread has one display, one D3D device, one renderer and so on?
2. What would be the downsides of having a D3D device per EGL display in regards of memory and throughput? From a throughput point of it seems to be the best solution as it requires minimum synchronization.
3. If it is feasible, what's the recommended way to instantiate a D3D device per display?
4. Using eglCreateDeviceANGLE? This API seems to work only with D3D11 which is unfortunate (though I'm not aware of how many D3D9 only devices are out there).
5. Using eglGetPlatformDisplayEXT with, for example, a static counter as EGLNativeDisplayType. I haven't got the time to test it, but from the code it looks like it will fall through nicely and it will properly create a device as requested in the attributes list.

Thanks for your help!

[austinkinross]

Hi Andrei,

Yes, creating multiple D3D devices is a supported way of achieving this for D3D11. To answer some of your questions:

• For XAML SwapChainPanel in UWP, this should work for a small number of SwapChainPanels. We don't recommend having more than a couple of SwapChainPanels in your application for optimum performance though.
• There shouldn't be any synchronization required within your ANGLE code for this.
• Each D3D device has a non-negligible memory overhead, but for a few D3D devices this should only be in the MBs or 10s of MB.
• Ultimately there will have to be synchronization performed here by the kernel as it composes your SwapChainPanels into the final scene, but this is a highly optimized path that is likely to be better than synchronization within ANGLE itself.
• I'm not sure if you are focused on UWP here or not (given that you mentioned SwapChainPanel), but you may wish to note that D3D9 isn't supported in UWP applications.
• Either option you have suggested should work for instantiating a D3D device per display.

Thanks!

[abucur]

Great info, thanks a lot! I'm really happy to hear this is a supported use case.

• The application is UWP but I remember reading D3D9 is still supported. It was probably about something else.
• For our use case there is a SwapChainPanel per Window. Is the performance restriction you are mentioning per Application or per Window? I imagine that the SwapChainPanel is composited in the Window (I remember seeing you can overlay XAML components on top of the SwapChainPanel) and from there it's the job of the Window manager to make the final composition.

[austinkinross]

The reason we recommend minimizing the number of SwapChainPanel is mostly because they are heavyweight objects. There isn't a certain number of SwapChainPanels after which you'll hit bad performance; you'll just take a performance hit for each one you create. It's a good idea to try to reduce the total number of them across your application.

Of course, if you are rendering OpenGL ES content to multiple windows then you'll need multiple SwapChainPanels- you can't avoid that. :-)

[austinkinross]

I believe your questions have been answered, so I'm closing out this issue. Feel free to reactivate it if you have further questions on this topic!