Войти
ПрограммированиеФорумГрафика

Тормозит 3D на NVIDIA графике на ноутбуках с Win10 (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая »
#15
17:58, 3 июня 2019

Нам нужен vsync и оконный режим. Exclusive режим экрана не подходит.

Эта проблема проявляется на всех ноутбуках с нескольми последними поколениями Intel и NVIDIA графики. И на Geforce 1050 и Geforce 920M, например.

Любые самые последние драйвера Geforce, Intel.

Любая версия Windows 10 начиная с 1803, 1809 и по 1903.


#16
(Правка: 23:49) 23:47, 3 июня 2019

а D3DPRESENT_INTERVAL_ONE и т.д. тоже погоды не делают?

Malder1
> Мы как раз написали небольшой тест (мы пишем на FreePascal/Lazarus/Delphi) для проверки проблемы.
а как его погонять? у меня есть ноут с Intel+NVidia

#17
0:01, 4 июня 2019

Могу проверить на GTX540M + Intel

#18
(Правка: 9:10) 9:09, 4 июня 2019

мы до недавнего времени поддерживали d3d9 и всё нормально работало. возможно, у вас неправильно обрабатываются просадки фпс? в смысле если один кадр проседает по времени, то следующий кадр может пытаться сделать два апдейта, чтобы наверстать, тратит на это ещё в 2 раза больше времени, из-за это следующий кадр снова считает 2 апдейта вместо одного и так далее. чтобы это проверить, сделай просто задержку по нажатию кнопки на секунду перед present'ом. если после того, как задержка отработает, фпс нормализуется, то дело не в этом.


ещё покажи результат профайлинга на intel gpa, потому что нет смысла гадать на кофейной гуще, что там у вас тормозит, когда можно просто посмотреть.

#19
17:29, 4 июня 2019

С D3DPRESENT_INTERVAL_ONE тоже тормозит как и с D3DPRESENT_INTERVAL_DEFAULT

Vsync как я понимаю в DWM (Win7/8/10) нельзя отключить в оконном режиме, т.к. мой рендеринг синхронизируется с рендерингом интерфейса Windows (DWM).

Проблема точно НЕ в расчете времени кадра (тайминг), поскольку тормозит сам Present() - его вызов занимает много времени и оно все увеличивается достигая 30 мс на один вызов Present() - т.е. сами понимаете, что если он торчит в Present() 30 мс, то отрендерить 60 кадров никак не получится.

Попробую подготовить отдельный тест, но он написан на Freepascal. Многие ли захотят запускать неизвестный EXE? Вот именно...

Позвольте снова напомню, что в Exclusive режиме все отлично.

И проблема точно такая же у нашего конкурирующего продукта написанного на C/C++.

Тормозит вывод скажем 2-3 прямоугольников с текстурами каждая по 2048 x 2048. Картинки просто плавно летят по экрану.

#20
(Правка: 17:35) 17:33, 4 июня 2019

Malder1
> Попробую подготовить отдельный тест, но он написан на Freepascal.
> Многие ли захотят запускать неизвестный EXE? Вот именно...
я могу собрать .exe.
Мне все доверяют!

а потом, тут половина участников на короткой ноге, что с FPC, что с Delphi.

#21
17:39, 4 июня 2019

Malder1
> Попробую подготовить отдельный тест, но он написан на Freepascal. Многие ли
> захотят запускать неизвестный EXE? Вот именно...
Я не буду запускать неизвестный exe, но могу собрать фрипаскалевский проект.

#22
18:44, 5 июня 2019

Кажется я нашел причину этой проблемы.

Мы используем SwapChain - CreateAdditionalSwapChain() и Present() вызывается у SwapChain.

После пробного удаления SwapChain и рендеринга напрямую скорость стала нормальной и быстрой.

Что за ерунда?

#23
(Правка: 4:12) 4:11, 6 июня 2019

Malder1
> Кажется я нашел причину этой проблемы.
Уже второй раз за два дня - написание отдельностоящего теста помогает быстро находить проблему.

#24
14:53, 6 июня 2019
Malder1

Мы используем SwapChain - CreateAdditionalSwapChain() и Present() вызывается у SwapChain.

После пробного удаления SwapChain и рендеринга напрямую скорость стала нормальной и быстрой.

Что за ерунда?

Предполагаю, что проблема в особенности реализации Optimus. Дело в том, что, обычно, в такой системе карточка NVIDIA вообще не подключена к видеовыходам и может только передавать буфер для отображения в Intel. Соответственно, сигнал синхронизации с частотой обновления экрана им приходится получать каким-то отдельным путём. Видимо, для AdditionalSwapChain этот механизм оказался поломан, поскольку она вообще никак не связана с дисплеем, пока не вызовется Present. В результате она то и дело пропускает интервал и ждёт следующего, что и приводит к проседанию fps примерно в 2 раза.

#25
(Правка: 16:16) 16:16, 6 июня 2019

Suslik
> ещё покажи результат профайлинга на intel gpa, потому что нет смысла гадать на
> кофейной гуще, что там у вас тормозит, когда можно просто посмотреть
odino4ka
> Предполагаю, что проблема в особенности реализации Optimus... Соответственно, сигнал синхронизации с частотой обновления экрана им приходится получать каким-то отдельным путём

(вопрос знатокам) есть ли инструментарий, способный такие вещи отслеживать?

#26
21:10, 6 июня 2019

До Windows 10 v1803 все отлично работало на Intel Optimus и разницы не было с обычным Present() без SwapChain'ов

#27
(Правка: 15:27) 15:20, 9 июня 2019

Курите функцию WinAPI timeBeginPeriod()

Без её использования Sleep() имеет по умолчанию дробность 18.5 милисекунд, что абсолютно непригодно для игр - т.е. вызываешь Sleep(1) - а она, самка собаки, спит случайное время от одной милисекунды до времени, больше времени одного кадра пр 60 фпс.

Хитрость тут в том, что timeBeginPeriod() устанавливает период прерываний таймера для *всей* системы - т.е. в любой момент этот период будет минимальным из тех, что устанавливали все приложения, что эту функцию дёргали.

А теперь вспоминаем, что, например, гуглохром любит эту штуку использовать (по крайней мере, так было несколько лет назад) - т.е. ваш метод. основанный на Sleep(), работает только когда запущен гуглохром (или любое другое приложение, запросившее милисекундный таймер).

Только не забывайте, что это снижает общесистемный КПД из-за более частого переключения потоков, а также вызывает повышенный расход энергии, что чувствительно для ноутбуков. Настоящие джентльмены не забывают вызывать timeEndPeriod() при потере фокуса приложением или переключении ноутбука на батарею.

P.S. Как это делаю я:

+ Показать

#28
19:29, 9 июня 2019

Я честно полагал, что TimeBeginPeriod() действует все время работы моего приложения.

Но проблема описанная в этом топике не связана с TimeBeginPeriod() - просто рендеринг через SwapChain очень МЕДЛЕННЫЙ (долго торчит в Present(), намного дольше чем нужно).

#29
23:07, 9 июня 2019

Я, когда экспериментировал несколько лет назад, наблюдал, что длительность вызова SwapBuffers() драматически возрастает, если в семёрке включена композиция экрана (с прозрачностью, спецэффектами и прочее) или поверх твоего окна попадает какое-нибудь окно с прозрачностью.
Может, родственно?

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумГрафика