There is really not that much of a performance gain you can expect from multithreading your game.

Sorry, but this is BS.

What is the correct approach to concurrent rendering while running game-logic?

The game logic is always hard to make concurrently with other engine parts due to its manipulative nature. Just think about a missle created ad-hoc in the game logic loop, you really need to be careful to not create all the necessary entities (physics, render model, sound files) on-the-fly and add them to the according sub-systems. In this case you should work with proxies which are in an invalid state until properly integrated at a given sync point.

As L.Spiro said, I think that multithreaded rendering, or atleast creating multiple command queue concurrently can help.

But there's still hope to optimize the rendering without using multithreaded rendering. The basic idea is , to fill up the rendering queue faster than the GPU is capable of processing it. Once the CPU is done, the GPU is still running leaving the CPU for other tasks:

Simplified tasks in a single frame

	  Render   Game logic			Physics  Audio
CPU |--------||------------------||---------||-----------|
GPU   |------------------------------|	 

If you don't want to touch the game logic you can try to extract as much as possible from the rendering task and process it concurrently like this

Simplified tasks in a single frame

CPU 1 |--| Render animation  
CPU 2 |-----|Rendering Pipeline
CPU 3 |---------| Physics
CPU 4 |--Audio---|S|---Game logic---|
GPU   |------------------------------|	

Ie extract the calculation of the animation for the next frame from your rendering pipeline (double buffering), no need to stall the pipeline filling here. S is the Syncpoint, that is, you start with the game logic once all the other tasks are proceed.

There is really not that much of a performance gain you can expect from multithreading your game.

Sorry, but this is BS.

What is the correct approach to concurrent rendering while running game-logic?

The game logic is always hard to make concurrently with other engine parts due to its manipulative nature. Just think about a missle created ad-hoc in the game logic loop, you really need to be careful to not create all the necessary entities (physics, render model, sound files) on-the-fly and add them to the according sub-systems. In this case you should work with proxies which are in an invalid state until properly integrated at a given sync point.

As L.Spiro said, I think that multithreaded rendering, or atleast creating multiple command queue concurrently can help.

But there's still hope to optimize the rendering without using multithreaded rendering. The basic idea is , to fill up the rendering queue faster than the GPU is capable of processing it. Once the CPU is done, the GPU is still running leaving the CPU for other tasks:

Simplified tasks in a single frame

 Render   Game logic			Physics  Audio
CPU |--------||------------------||---------||-----------|
GPU   |------------------------------|		[/font]

If you don't want to touch the game logic you can try to extract as much as possible from the rendering task and process it concurrently like this

Simplified tasks in a single frame

CPU 1 |--| Render animation  
CPU 2 |-----|Rendering Pipeline
CPU 3 |---------| Physics
CPU 4 |--Audio---|S|---Game logic---|
GPU   |------------------------------|	 

Ie extract the calculation of the animation for the next frame from your rendering pipeline (double buffering), no need to stall the pipeline filling here. S is the Syncpoint, that is, you start with the game logic once all the other tasks are proceed.

There is really not that much of a performance gain you can expect from multithreading your game.

Sorry, but this is BS.

What is the correct approach to concurrent rendering while running game-logic?

The game logic is always hard to make concurrently with other engine parts due to its manipulative nature. Just think about a missle created ad-hoc in the game logic loop, you really need to be careful to not create all the necessary entities (physics, render model, sound files) on-the-fly and add them to the according sub-systems. In this case you should work with proxies which are in an invalid state until properly integrated at a given sync point.

As L.Spiro said, I think that multithreaded rendering, or atleast creating multiple command queue concurrently can help.

But there's still hope to optimize the rendering without using multithreaded rendering. The basic idea is , to fill up the rendering queue faster than the GPU is capable of processing it. Once the CPU is done, the GPU is still running leaving the CPU for other tasks:

Simplified tasks in a single frame

[font=courier new,courier,monospace]	  Render   Game logic		    Physics  Audio
CPU |--------||------------------||---------||-----------|
GPU   |------------------------------|        [/font]

If you don't want to touch the game logic you can try to extract as much as possible from the rendering task and process it concurrently like this

[font=courier new,courier,monospace]Simplified tasks in a single frame[/font]

[font=courier new,courier,monospace]CPU 1 |--| Render animation   
CPU 2 |-----|Rendering Pipeline[/font]
[font=courier new,courier,monospace]CPU 3 |---------| Physics[/font]
[font=courier new,courier,monospace]CPU 4 |--Audio---|S|---Game logic---|[/font]
[font=courier new,courier,monospace]GPU   |------------------------------|	  [/font]

Ie extract the calculation of the animation for the next frame from your rendering pipeline (double buffering), no need to stall the pipeline filling here. S is the Syncpoint, that is, you start with the game logic once all the other tasks are proceed.