DirectX 11 Swap Chain with 7 back buffers

Question

I have a propietary media player that runs on Windows 8 in desktop mode. Runtime DirectX version is 11, but native graphics driver support is for DirectX 9.
On some computers with the exact same setup, I see that the actual swap chain's back buffers count is 2, and the performance is great, and on some others the back buffer count is 7 and there are frames dropped.
I don't have the source code of that player and wonder what could be the reason for determining the different back buffer count number in runtime.
Can someone please explain why such backbuffer count leads to such change in performance? Or just point me to relevant documentation that explains the implications of backbuffers number?

(More debugging info: Using GPUView I see that when backbuffer count is 2 the hardware works in a synchronized mode, i.e. one packet in the HW queue in each second VSync (Clip frame rate is 30fps), when for the 7 backbuffers the work is done for 5-7 frames together, then some empty VSyncs, then 5-7 frames again and so on).

Thank you in advance!

Answer 1

Well, I got an answer from Microsoft. This is in order to save power when working on DC (battery) - that way the processor can be awake for processing all available buffers, send them to GPU to work on and move to a deeper power saving mode for a longer time.

Answer 2

I don't really see the use of having more than 4 buffers (quad buffering, which is used for stereoscopy). Most applications use 2 buffers (double buffering) so that the application can start drawing the next frame to the second (back) buffer while the first (front) buffer is being presented to the monitor, otherwise, the application will have to wait until the front buffer is finished drawing to the screen before it can start drawing the next frame. Triple buffering just expands on this idea, so that there are two back buffers. This way, if the application is able to finish drawing an entire buffer faster than the front buffer takes to be presented to the screen, then it can start drawing the next frame to the third buffer instead of waiting for the front buffer to finish presenting.

I'm not sure if that really answers your question about other apps using 7 buffers, but again i don't think there's a need, since monitors only refresh at a rate of 60 to 75Hz usually.

If your application is running that fast that it is able to draw 2 buffers before the first buffer is finished presenting, just put the app to sleep until the front buffer is finished to give some other programs a chance to use the cpu, or spend that extra time doing some other processing for your app. If it's a media player, you could spend that extra time doing some more expensive operations to increase the quality of the media's playback.

here's a link describing buffering though, but they don't talk about more than 4 buffers, probably because there is no need.

http://en.wikipedia.org/wiki/Multiple_buffering

P.S. maybe the reason why the application probably loses some frame rate when using like 7 buffers, is because the application probably can't keep up writing to all of the buffers before they need to be presented to the screen. This probably wouldn't be the case if multi-threading was being used, because then the next buffer could be presented to the screen before the app finished drawing to all the other back buffers.