DirectX 11 Swap Chain с 7 обратными буферами

Question

У меня есть проприетарный медиаплеер, который работает в Windows 8 в рабочем режиме. Runtime DirectX версии 11, но поддержка встроенного графического драйвера для DirectX 9.
На некоторых компьютерах с точно такой же настройкой я вижу, что фактическое количество обратных буферов в swap-цепочке равно 2, а производительность велика, а на некоторых других счетчик обратного буфера равен 7, и снижаются кадры.
У меня нет исходного кода этого плеера и не знаете, что может быть причиной определения количества счетчиков обратного буфера во время выполнения.
Может ли кто-нибудь объяснить, почему такое количество backbuffer приводит к такому изменению производительности? Или просто укажите мне соответствующую документацию, которая объясняет последствия числа бэкбуферов?

(Дополнительная информация об отладке: Использование GPUView Я вижу, что, когда количество обратных буферов равно 2, оборудование работает в синхронизированном режиме, то есть один пакет в очереди HW в каждой секунде VSync (частота кадров клипа составляет 30 кадров в секунду), когда для 7 backbuffers работа выполняется для 5-7 кадров вместе, затем несколько пустых VSyncs, затем 5-7 кадров и т. д.).

Спасибо заранее!

Answer 1

Ну, я получил ответ от Microsoft. Это делается для того, чтобы экономить электроэнергию при работе с DC (батареей) - таким образом, процессор может бодрствовать для обработки всех доступных буферов, отправлять их на GPU для работы и более длительного режима энергосбережения.

Answer 2

Я действительно не вижу использования более 4 буферов (квадрантная буферизация, которая используется для stereoscopy). В большинстве приложений используется 2 буфера (двойная буферизация), так что приложение может начать рисовать следующий кадр во втором (обратном) буфере, пока первый (передний) буфер отображается на мониторе, в противном случае приложению придется ждать, пока передняя буфера завершается рисованием на экране, прежде чем он сможет начать рисовать следующий кадр. Тройная буферизация просто расширяет эту идею, так что есть два задних буфера. Таким образом, если приложение сможет завершить рисование всего буфера быстрее, чем передний буфер принимает на экран, тогда он может начать рисовать следующий кадр в третий буфер, а не ждать, пока передний буфер закончит презентацию.

Я не уверен, что это действительно отвечает на ваш вопрос о других приложениях с использованием 7 буферов, но опять-таки я не думаю, что есть необходимость, так как мониторы только обновляются со скоростью от 60 до 75 Гц.

Если ваше приложение работает так быстро, что оно может нарисовать 2 буфера перед завершением первого буфера, просто заставьте приложение спать до тех пор, пока передний буфер не будет готов, чтобы дать другим программам возможность использовать процессор , или потратьте дополнительное время на выполнение какой-либо другой обработки для вашего приложения. Если это медиаплеер, вы можете потратить дополнительное время на выполнение более дорогих операций, чтобы повысить качество воспроизведения мультимедиа.

вот ссылка, описывающая буферизацию, хотя они не говорят о более чем 4 буферах, возможно потому, что нет необходимости.

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

P.S. возможно, причина, по которой приложение, вероятно, теряет некоторую частоту кадров при использовании, например, 7 буферов, заключается в том, что приложение, вероятно, не успевает писать все буферы, прежде чем их нужно будет отображать на экране. Вероятно, это было бы не так, если бы использовалась многопоточность, потому что следующий буфер мог быть представлен на экране до того, как приложение закончило рисование ко всем остальным буферам.