Почему приложение Direct3D работает лучше всего в полноэкранном режиме?

Question

Производительность приложения Direct3D кажется значительно лучше в полноэкранном режиме по сравнению с оконным режимом. Каковы технические причины этого?

Я полагаю, что это имеет какое-то отношение к тому факту, что полноэкранное приложение может получить исключительный контроль над дисплеем. Но почему приложение не может получить эксклюзивный контроль для части экрана (то есть окна) и имеет те же преимущества в производительности?

Answer 1

Вот скалы заметки о том, как вещи работают под ним.

Экран монитора всегда должен быть связан с so-ca чтобы иметь возможность отображать что угодно, то есть видеокарта может сканировать только одну поверхность в видеопамяти.

Когда приложение полноэкранное (и все было настроено правильно, чтобы разрешить перелистывание), основная поверхность является всего лишь одним из прикладных backbuffers и перевернута на другой буфер для каждого кадра. Это самый эффективный способ представления на экране, но для этого требуется приложение для владения всей областью монитора (т. Е. Всей первичной поверхностью).

Когда нет полноэкранного приложения и DWM выключен, основная поверхность принадлежит ОС, и каждое оконное приложение выполняет блик от приложения backbuffer до первичной поверхности. Этот blit занимает некоторое время GPU для завершения (а также блики от других приложений, видимых на экране), поэтому он не так эффективен, как полноэкранная презентация. XP работал именно так.

Когда DWM создает экран, все становится еще сложнее. Здесь DWM владеет первичной поверхностью и нуждается в рисовании окон приложений. Чтобы это стало возможным, каждое окно имеет связанную поверхность, содержащую его содержимое, называемую поверхностью перенаправления (что позволяет DWM разрешать ореолы окна, эффекты стекла и все эти хорошие вещи). Каждый раз, когда приложение D3D выдает фрейм, он добавляет blit к поверхности перенаправления. Таким образом, должно произойти несколько blits: blit to redirection surface by app, blit от поверхности перенаправления до первичной DWM, что опять-таки накладные расходы по сравнению с полноэкранным.

Обратите внимание, что все дополнительные работы выполняются на графическом процессоре, поэтому это не влияет на производительность ЦП.

Материал читать далее:

http://blogs.msdn.com/greg_schechter/archive/2006/03/19/555087.aspx

http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx

http://blogs.msdn.com/greg_schechter/archive/2006/03/05/544314.aspx

Answer 2

В MSDN есть a bit, в котором говорится, что режим полного экрана использует сброс буфера, если он настроен правильно, в отличие от биения. Это имеет смысл.

Конечно, вы можете (и в некотором смысле сделать) предоставить эксклюзивный контроль части экрана на приложение, но что происходит с остальной частью экрана? Вы все еще должны blit, делать проверку окклюзии и т. Д. На остальных окнах, и я думаю, что это то, что приводит к поражению.

Answer 3

Я добавлю к ответу @aib, что остальная часть экрана находится под управлением ОС. Итак, если что-то еще нужно рисовать/обрабатывать одновременно, должен быть удар производительности.

Например, если у вас есть видео, воспроизводимое в проигрывателе Windows Media в одном окне, тогда запустите Civilization в другом, когда Civ начнет делать свою причудливую графику, ему нужно будет разделить пространство экрана со всем остальным (например, видео.

Принимая во внимание, если приложение DirectX имеет полный экран, все остальное может быть «обновление» или «играть», но не втягивается.

Answer 4

В принципе, видеоплаты полностью посвящен применению только в режиме.

Там нет конкуренции за видео ресурсов (трубопровод, текстуры памяти, и т.д. ...)

В частности, структура загрузки может быть узким местом. Чем меньше вы должны это делать (потому что у вас есть все), тем лучше.