DirectX 11 Swap Chain with 7 Reverse Buffers

Question

I have a proprietary media player that runs on Windows 8 in desktop mode. The version of Runtime DirectX is 11, but the support for integrated graphics drivers is for DirectX 9.
On some computers with exactly the same setting, I see that the actual number of buffers in the reverse circuit is 2, and the performance is great, and on some others the counter of the inverse buffer is 7, and frames are reduced.
I do not have the source code for this player and I wonder what could be the reason for determining the number of counting the number of inverse buffers at runtime.
Can anyone explain why so many backbuffers lead to such a performance change? Or just point me to the relevant documentation that explains the consequences of the number of back buffers?

(Additional information about debugging: using GPUView, I see that when the number of reverse buffers is 2, the equipment works in synchronized mode, that is, one packet in the HW queue in every second VSync (clip frame rate is 30 frames per second) when for 7 backbuffers, work is done for 5-7 frames together, then several empty VSyncs, then 5-7 frames, etc.).

Thank you in advance!

Answer 1

Well, I got a response from Microsoft. This is done in order to save energy when working with DC (battery) - in this way, the processor can be awake to process all available buffers, send them to the GPU for work and a longer power-saving mode.

Answer 2

I really don't see the use of more than 4 buffers (quad-buffering, which is used for stereoscopy ). Most applications use 2 buffers (double buffering), so the application can start drawing the next frame in the second (reverse) buffer while the first (front) buffer is displayed on the monitor, otherwise the application will have to wait for the front buffer to finish drawing on the screen before he can start drawing the next frame. Triple buffering simply extends the idea, so there are two back buffers. Thus, if the application can finish drawing the entire buffer faster than the front buffer takes on the screen, then it can start drawing the next frame to the third buffer, and not wait for the front buffer to finish the presentation.

I'm not sure if this is the answer to your question about other applications using 7 buffers, but again I don’t think it is necessary, since monitors only update at a speed of 60 to 75 Hz usually.

If your application runs so fast that it can draw 2 buffers before completing the first buffer, just make the application sleep until the front buffer is complete, to allow other programs to use the processor, or spend extra time doing some other things for your application. If this is a media player, you can spend extra time on more expensive operations to improve the quality of multimedia playback.

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

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

PS perhaps the reason that the application is likely to lose some frame rate when using, for example, 7 buffers, is because the application probably does not have time to write all the buffers before they need to be displayed on the screen. This would probably be wrong if multithreading was used, because the next buffer could be displayed on the screen before the application finished drawing to all other buffers.