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

Что лучше VSYNC или неограниченное ФПС (8 стр)

Страницы: 14 5 6 7 8 9 Следующая »
#105
20:11, 9 ноя. 2011

Lamer007
нашел ответ
http://www.geisswerks.com/ryan/FAQS/timing.html
там внизу про ограничение фпс, которое не жрет проц.
так себе его и представлял, только не знал, как делать точный sleep.
спс за timeBeginPeriod/timeEndPeriod

Lamer007
> А где хотите? В "полном цикле" планировщика задач?
ну он же не грузит проц 100%. проц не греется, энергию не требует.
или я неверно фантазирую? просто я не знаю, что значит "загрузка процессора" и как оно управляется системой. даже не системой, а именно что такое с точки зрения архитектуры "загрузка процессора" и чем это отличается от "бездействия".
(я знаю, что у меня на ноуте из 2ггц становится 1ггц, когда процессор "не загружен". но все равно не понимаю...)

Lamer007
> Во время работы потока, если он правильно устроен, и так много ожиданий:
> ожидание своего таймслайса, файловый IO, IO в видеокарту, ожидание событий и
> тд.
да это я понимаю. но если у меня на экране 400фпс, а мне надо 60, то зачем я буду киловатты матать на счетчик геймеру своей игрой?


#106
20:13, 9 ноя. 2011

Lamer007
>Такой sleep не нужен. Можно и нужно обходится другими средствами. Это не средство измерения времени. А как средство экономии ЦПУ - от него толку мало, если использовать его после форсирования точного режима в 1 мс. >Да и после форсирования нечего ожидать, что управление через 1 мс вернется, тк оно может уйти к кому-то другому. Тем более форсирование к точному режиму приводит к потере производительности.
>И вообще, это не система реального времени, чтобы ждать от Sleep точности.
А кто вообще говорил про использование sleep как замера времени? Это ваша интерпретация, я такого нигде не говорил.
Речь идёт о чувствительности такого sleep'a, когда хочется отдать больше времени других потокам или процессам. Можно конечно обойтись sleep(0), но пользы будет меньше, а с погрешностью в 16 миллисекунд далеко не пойдёшь! Писать приложение, которое отжирает 100% ресурсов процессора - свинство, как минимум по отношению к пользователю.

Если использовать классический VSync, то вызывая SwapBuffers() мы мирно ждём драйвер, прожирающий CPU в цикле (во всяком случае такого поведение большинства OpenGL драйверов).

>> не хочу просирать время в пустом цикле.
>А где хотите? В "полном цикле" планировщика задач?
А что такого плохого в планировщике задач? Это его работа - раздавать процессорное время процессам.

#107
20:24, 9 ноя. 2011

"квинтэссенция"
However, if you need to do
any kind of "timed pauses" (such as those necessary for framerate limiting), you
need to be careful of sitting in a loop calling QueryPerformanceCounter, waiting
for it to reach a certain value; this will eat up 100% of your processor.  Instead,
consider a hybrid scheme, where you call Sleep(1) (don't forget timeBeginPeriod(1)
first!) whenever you need to pass more than 1 ms of time, and then only enter the
QueryPerformanceCounter 100%-busy loop to finish off the last < 1/1000th of a
second of the delay you need.  This will give you ultra-accurate delays (accurate
to 10 microseconds), with very minimal CPU usage.

#108
20:58, 9 ноя. 2011

EvilSpirit
> ну он же не грузит проц 100%. проц не греется, энергию не требует.
Планировщик занимается переключением задач, а только потом, если готовых к переключению задач не найдено, то он уходит в цикл ожидания, выполняя инструкцию HLT. Если период ожидания слишком затягивается или загрузка процессора сильно низкая, то драйвер управления питанием COOL&QUIET переводит процессор и куллер в режим пониженного энергопотребления.

gkv311
> Писать приложение, которое отжирает 100% ресурсов процессора - свинство
А 99.9% загрузки ЦП уже не свинство, которые мы получим из-за Sleep(1)? Или схватить лишние тормоза (сниженный FPS и скорость реакции) из-за излишне частой работы планировщика (после вызова timeBeginPeriod) не свинство? Почитайте "труды" Криса Касперского на эту тему, если вы профессионально играми или высокопроизводительными приложениями занимаетесь.

>Писать приложение, которое отжирает 100% ресурсов процессора - свинство, как минимум по отношению к пользователю.
Вы не поверите, но можно писать игры без слипов в цикле рендера без 100% загрузки ЦП.

>Если использовать классический VSync, то мирно ждём драйвер, прожирающий CPU в цикле
Вы не поверите, но VSync - не единственное место ожидания процессором видеокарты (точнее монитора в случае VSync). Есть и другие устройства и события, которых приходится ожидать. Кстати, DirectX может ожидать по событию VSync, не пожирая ЦП, хотя это не рекомендуется, тк сильно маленький период ожидания и планировщик может "проморгать".

#109
21:11, 9 ноя. 2011

Lamer007
> Вы не поверите, но можно писать игры без слипов в цикле рендера без 100%
> загрузки ЦП.
скажи нам, как?

#110
21:16, 9 ноя. 2011

Lamer007
>А 99.9% загрузки ЦП уже не свинство, которые мы получим из-за Sleep(1)?
Если у вас получается 99.9% загрузки CPU - то это проблема в вашем коде, а не моём.
Для меня излишняя загрузка процессора - это не просто неприятность, а непригодность,
потому что моё приложение работает сутками параллельно с рабочими процессами.

>Или схватить лишние тормоза (сниженный FPS и скорость реакции) из-за излишне частой работы планировщика (после вызова timeBeginPeriod) не свинство?
Очнитесь, если этого не сделаете вы, то наверняка в системе найдётся 'серое' приложение от именитого производителя (ну например Firefox), которое переключит таймер на адекватное состояние без вашего участия!

>Вы не поверите, но VSync - не единственное место ожидания процессором видеокарты (точнее монитора в случае VSync). Есть и другие устройства и события, которых приходится ожидать.
Каждый решает свои проблемы. Если вы с такой ситуацией не сталкивались, это ещё не значит, что эта проблема выдумана.

#111
21:43, 9 ноя. 2011

EvilSpirit
> скажи нам, как?
Уже говорил выше, главное правильно использовать окружение и правильно организовывать многопоточность. И вспомните ещё одно, на современных игровых (это важно) компьютерах есть не менее 2х ядер. Тут очень легко получить 50% загрузку ЦП, используя в игре лишь один поток. Это шутка, конечно, но в каждой шутке есть доля правды.

gkv311
> Для меня излишняя загрузка процессора - это не просто неприятность, а непригодность, потому что моё приложение работает сутками параллельно с рабочими процессами.
Если вы написали игровой сервер, то это понятно, только причем тут игровой сервер, FPS и Sleep? Я то говорил про слипы в клиентской части игры.

> 'серое' приложение от именитого производителя (ну например Firefox), которое переключит таймер на адекватное состояние без вашего участия!
Ну вот это уже свинство. :)

>Если у вас получается 99.9% загрузки CPU - то это проблема в вашем коде, а не моём.
Поймите, если все верно организовать, то будет достаточно низкая (для среднестатистической игры, конечно) загрузка ЦП и мелкие Sleep в рендере не сильно на что-то повлияют. Если же загрузка ЦП и так большая и ФПС близок к лимиту или ниже положенного, то вызовы слип и частый не обоснованный вызов планировщика по системному прерыванию только снизят ФПС и реакцию игры ещё ниже.

#112
21:48, 9 ноя. 2011

Lamer007
> Поймите, если все верно организовать, то будет достаточно низкая (для
> среднестатистической игры, конечно) загрузка ЦП и мелкие Sleep в рендере не
> сильно на что-то повлияют. Если же загрузка ЦП и так большая и ФПС близок к
> лимиту или ниже положенного, то вызовы слип и частый не обоснованный вызов
> планировщика только снизят ФПС и реакцию игры ещё ниже.
это работает только с vsync. а если мне не нужен vsync, у меня графики, допустим, нет. но мне надо 100 раз в секунду вызываться (в среднем) и при этом тихо мирно сидеть в памяти и не жрать лишнего?

#113
22:11, 9 ноя. 2011

EvilSpirit
> но мне надо 100 раз в секунду вызываться (в среднем) и при этом тихо мирно сидеть в памяти и не жрать лишнего?
То есть вы не про клиентскую часть игры? Можно пример такой задачи, где требуется с частотой 100 Гц вызывать нечто?

#114
22:47, 9 ноя. 2011

EvilSpirit
> скажи нам, как?
  Есть WaitForSingleObject. В отличие от Sleep считает время с последнего срабатывания, а не с начала вызова, поэтому можно получить абсолютно точный интервал независимо от времени рендеринга.

#115
8:56, 16 фев. 2012

Подскажите пожалуйста. Использую и vsync, и sleep с подгоном задержки. Получается два предела частоты: один (меньший) задаётся vsync, другой (заведомо больший) задаётся sleep. Делаю это на случай, если пользователь отключает vsync (а сделать он это может, насколько знаю, и в обход игры), чтобы видеокарта и cpu не кипели на максимуме попусту. Проблема в выборе частоты для sleep. Какая сейчас самая большая частота у мониторов? 100? 200?

#116
11:34, 16 фев. 2012

В мониторах, я видел максимум 120 Гц(может есть и больше), но можно же подключить и к телевизору :)(так делал я), а они есть по 400-600 Гц. Но не факт что видеокарта, даже на HDMI выходе даст столько. Наверное нужно все таки иметь возможность управлять синхронизацией из приложения.

#117
14:08, 16 фев. 2012

Это что за телеки такие страшные? :) Поставил в общем 150, пока не очень критично.
Правда напоролся на другое, иногда проявлялись небольшие глюки, как будто один кадр вывалился или прорисовался с нулевым Δt. FPS выдавал стабильно кадровую частоту. Начал мониторить Δt, он оказался в общем случае равномерным, но с небольшими проскоками, например так: 13 13 14 13 13 6 22 13 14 13. Далее попробовал отдельно следить за рендером и свопом.

  ft := SDL_GetTicks;
  Render;
  glFinish;
  ft := SDL_GetTicks - ft;

  st := SDL_GetTicks;
  SDL_GL_SwapBuffers;
  glFinish;
  st := SDL_GetTicks - st;
Узнал что все команды кешируются. Даже SwapBuffers. Добавил glFinish чтобы показало реальное время, а не время кеширования. Результат:
ft = 0..11
st = 0..26
SDL_GL_SwapBuffers выполняется иногда дольше чем время целого кадра (Может что-то SDL косячит?). Vsync включен, Частота монитора 75 Гц. То есть, один кадр 13,33(3) мс. А здесь 26 только на своп.. Магия? Конечно, понимаю, что нужно оптимизировать ft, слишком он жирный, но st объяснить не могу.

То же самое, без vsync (fps примерно 160):
ft = 1..8
st = 0..11

Why so slow? Я конечно понимаю что видеопамять работает несколько иначе чем обычная, но... Неужели она реально ждёт пока блок памяти уйдёт в монитор? И всё работает на максимальном фпс только благодаря адскому кешированию? (Или это проблема синхронизации драйвера с видеокартой? Да, кстати, приложение оконное + работает компиз - этим можно объяснить?)

#118
14:23, 16 фев. 2012

А ты думаешь кроме твоего процесса ничего больше нет? Не уложился в квант времени - ос переключает на другую задачу. Потом когда-то возвращается к твоей и тут ты замеряешь дельтатайм и опа - он вдруг подскакивает. Уменьшение можно объяснить тем, что буфер команд драйвера еще не заполнился и ничего не ушло на видеокарту.

#119
14:32, 16 фев. 2012

Но почему тогда просто не падает FPS? Допустим погремел там чего-то хард, что-то там по крону сработало, это видно, FPS падает на 1-2. Но здесь не падает. При том эти малозаметные рывки происходят довольно часто без видимой на то причины, раз-два в секунду (ничего больше не запущено, хм... хотя, сейчас попробую без дебага скомпилировать, всё равно не пользуюсь)

Страницы: 14 5 6 7 8 9 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.