Jump to content
  • Advertisement
AxeGuywithanAxe

DX11 Rendering Thread Architecture

This topic is 534 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I wanted to ask a question pertaining to rendering thread architecture. I currently know of two main designs.

One approach is where visibility , drawcall logic, and gpu submission are all done on the rendering thread and render related game data is sent to the rendering thread at the end of the frame. 

The second approach is where the sole responsibility of the rendering thread is to send gpu commands to the api. Engine abstacted Command Buffers will be generated in parallel or on the game thread, and sent to the rendering thread to be translated into gpu commands.

I know that Engines such as Unreal Engine use the first approach, while Unity / Source use the second approach , and Cryengine uses a hybrid of both. I wanted to see if anyone could give some advice, I know some of the benefits of both approaches , but wanted to get more incite on the architecture.

Share this post


Link to post
Share on other sites
Advertisement

My current architecture is one game thread , one rendering thread, and two worker threads. Both the rendering thread and the game thread can access the workers, i.e the rendering thread does visibility culling on up to three threads (including the rendering thread).  I have "scene proxy" objects that contain all data for rendering , and are synced at the end of the game frame. My issue with this architecture is that it doesn't fully utilize the strengths of DX12 and Vulkan. I would not need a dedicated thread , I guess to solve this, I could check the API that the user has and scale accordingly? I.e if the user is using DX11 or OpenGL I use the dedicated thread approach , and if the use is using vulkan , I will not have a dedicated rendering thread and just use all four cores for API command buffer generation. I've seen that some engines still use the dedicated rendering thread , but also use their job systems to create the command lists, and then call ExecuteCommandList on the dedicated thread, but that doesn't seem like an optimal approach.

Share this post


Link to post
Share on other sites

I use a similar arch, but the gameplay / render threads are also part of the pool and will attempt to execute jobs when idle. This means that rendering work can run on all 4 threads.

The rendering thread can kick off draw-call submission to the job system if you've got a lot of draws. Yeah, I expose a caps variable describing whether threaded command buffers are supported (D3D11) and whether they're actually recording HW commands (D3D12/Vulkan) or not.

On D11, I use a deferred context to record my GUI commands on another thread, just because GUI traversal is expensive and it's intertwined with draw submission. 

For the main scene, I cull and collect drawables in a platform independent manner. Then on D11/GL, one thread records them to the immediate context.

On D12/Vulkan, they're broken into batches that are thrown into the job queue for recording to many command buffers. These jobs could submit those command buffers to the GPU, but that would result in non-deterministic draw ordering. To preserve ordering, one thread submits all of the command buffers in a single call after those jobs have completed. 

Share this post


Link to post
Share on other sites

Ah , I see . Do you cull and collect drawables on the rendering thread ( i.e the rendering thread + worker threads ) ? Or do you cull / collect drawables on the game thread (game thread+ worker threads) and then send "drawitems" to the rendering thread to be translated into dx11 calls?

Share this post


Link to post
Share on other sites

Yeah, I take a snapshot of the gameplay state and pass it from the game thread to the render thread, which includes object transforms, etc...

The render thread then culls and extracts draw-items. Generally there's many draw-items for a single model, which the game doesn't care about. It just wants to place a model in the world, not care that it's made up of 100 sub-meshes.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!