5
$\begingroup$

I had an application that was originally single threaded and worked as follows:

  1. gather the items to be drawn (occlusion / frustrum culling / sorting into batches)
  2. draw items using an immediate context
  3. present

I decided to use a deferred context and parallelize step 2 as follows:

  1. gather the items to be drawn (occlusion / frustrum culling / sorting into batches)
  2. draw items in parallel used a deferred context
  3. execute the command lists for step 2)
  4. present

However, I saw almost no performance benefit. I finally decided move the "execute command lists" after present:

  1. gather the items to be drawn (occlusion / frustrum culling / sorting into batches)
  2. draw items in parallel used a deferred context
  3. present (is actually presenting the previous frame's scene now)
  4. execute the command lists

I saw a huge increase in performance with this method. My theory as to why is this worked is that the are basically 3 bottlenecks

  1. graphics card (triggered by present)
  2. my app's cpu thread
  3. device driver cpu thread (triggered by executing the command lists)

In my original order, each successive stage was blocked by the previous one to be finished. However now, I believe that all three are running in parallel:

  1. present with (frame - 2) data
  2. device driver thread with (frame - 1) data
  3. my cpu thread to run with this frame's data

My question is, is this a common pattern or is there some better way to achieve maximum parallization while using deferred context rendering?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.