Цепочка обмена DirectX 11 с 7 задними буферами

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

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

Заранее спасибо!


performance directx-11 directx windows-8 dxva
person rkellerm    schedule 04.06.2012    source источник

Ответы (2)


arrow_upward
7
arrow_downward

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

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

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

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

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

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

person iedoc    schedule 07.06.2012

arrow_upward
4
arrow_downward

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

person rkellerm    schedule 19.11.2012