Hello.

My app uses a thread to render and the main thread to update. After see some Gamefest presentations, I am trying to implement multiple buffering. The fact is that when creating the swap-chain with more that 1 buffer (I assume that if introducing 1 as the BufferCount, it is the front-buffer) the performance is quite improved.

So, is that the way to implement multiple-buffering, DXGI just manages it?

There are multiple forms of multi-buffering. The multi-buffering the swap chain does has more to do with preventing rendering to a front buffer (which is typically slow and can produce tearing). Multi-buffering also is used to enable parallelism between multiple processing units. Traditionally, muti-buffering was used to ensure the GPU would be able to work on frame N, while the CPU worked on frame N+1. Now with multicore CPUs, the same technique is being discussed in light of enabling parallelism between CPU cores. DXGI manages the swap chain aspects, while the application must manage the parallelism aspects.

Ok, thank you.

 I am interested in enabling parallelism between some threads (the typical Update/Render paradigm). Could you tell me some advice about it?

The fact is that I have researched 'bout this, but every page I found talks about double buffer in DirectX 9. You know, the application updates one frame, while the runtime manages the front buffer, not talking about managing multiple buffers.

I'm unsure what your 'typical' Update/Render paradigm entails, but the concept is rather simple. The Update thread usually hands off data to the Render thread. If you only have one piece of data, then the data is usually protected with synchronization (which would only let one thread manipulate it at a time); and the Update thread would not be able to concurrently generate the data while the Render thread worked on it. The general concept of multibuffering is to have two pieces of data and ping-pong between the two, such that Update can concurrently generate data, while Render works on the previous data. In the past, it has been intuitive to multi-buffer D3D resources, such as textures and queries. But, recently, it has become more popular for people to attempt to multi-buffer the graphics command stream, itself.

Brian Klamik:

The general concept of multibuffering is to have two pieces of data and ping-pong between the two, such that Update can concurrently generate data, while Render works on the previous data.n

This was what I refered to. any hint about how to achieve it?

Hi trogo

I wanna implement double buffering..

COuld u tell me hoe i can create a thread for rendering..

thank you

duodevil:

Hi trogo

I wanna implement double buffering..

COuld u tell me hoe i can create a thread for rendering..

thank you

Sure.

I have post the code about how the thread is created in pastebin.com. The same about how the threaded function here.

It sounds like you need to double-buffer at the application layer, which has nothing to do with Direct3D.
Your Update function will want to mutate the state of the game (a bunch of combinations of position/orientation/velocity/model/effect information in a scene graph, typically).
Your Render function will want to present a scene based on that same scene graph information.
To avoid a read/write hazard, you have to create a copy of your scene graph data, and hand off to the render thread, for each frame, while the Update function goes on mutating the scene graph in place. Alternatively, you can create two scene graphs, and copy from old to new each frame, but it boils down to the same thing.

So, your update will look something like:

  update_loop() {
    if (!rendering_running) {
      copy_data_to_renderer(game_state);
      rendering_kickoff();
    }
    update_one_physics_step();
  }

  render_loop() {
    wait_for_kickoff();
    render_state(game_state_copy);
    rendering_running = false;
  }

  rendering_kickoff() {
    rendering_running = true;
    set_event(render_event);
  }

Yes, you'll have to figure out what the proper primitive is for each part of those loops (rendering_running needs to be volatile, you'll need to handle termination requests, etc), but this sketch should show you how it can be made to work at the application level.

OMG! Thank you a lot jwatte.

Nowadays I am restructuring my codebase (switching it to OOP), so it will last some time until I implement this algorithm.