If I decouple the rendering stuff to a dedicated multithreaded renderer,
what is left to the main thread to do is to collect transformations
from the main effect components, game objects and their components,
and hand them over to the renderer.
Is it too trivial to do this?
I mean if I had a thousand agents, this is going to make a difference.
If I just got 10-100 objects in the scene, won't it be a waste to create
a standalone multithreaded renderer?
Thanks
Jack
In D3D 11 or OpenGL, there is little or no benefit to actual multithreaded rendering. There is a benefit from doing as much work as possible in multithreaded setup for rendering - you can map a bunch of buffers and write to them simultaneously from threads, you can load geometry and store draw calls, you can sort for the most efficient render order, etc. The benefit from these things just depends on you to set up your system to do as much work as possible with independent threads working in their own memory space and compiling the results efficiently.
In the case of D3D 12 or Vulkan, there are massive gains to be had from fully multithreaded draw submission as the draw call counts get large. Note that a thousand isn't considered large anymore if you're setting up your rendering efficiently, not stalling, not doing lots of state changes, etc. Think tens of thousands.
I suggest you go on with your game and only concern about rendering performance when it actually becomes a problem.
