Доброго времени суток, уважаемые игроделы.
Программированием графики занялся недавно
и поэтому вопровов пока больше чем ответов.
Начал я с уроков NeHe. На днях заметил одну
странную особенность программ на OpenGL --
даже каркас приложения неотображающий
ничего грузит проц на все 100 %. Сначала я
подумал, что хромает моя реализация программы,
но потом запустил екзешник от NeHe -- картина
та же самая. Почему так происходит?

Видеокарта без поддержки 3D, вот оно видимо и грузит проц.

Корень зла в цикле выборки сообщений. Следующая программа (заметьте, ничего общего не имеющая с OpenGL, DirectX, 3D и прочим) грузит процессор. В примерах от NeHe используется практически точно такой же код для цикла выборки оконных сообщений.

Код

#include <tchar.h> #include <windows.h> void render(void) { } LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) {     switch (msg)     {     case WM_DESTROY:         PostQuitMessage(0);         break;     default:         return DefWindowProc(hwnd, msg, wparam, lparam);     }     return 0L; } int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE, LPTSTR, int nCmdShow) {     WNDCLASSEX wc = {0};     wc.cbSize = sizeof(wc);     wc.hbrBackground = GetSysColorBrush(COLOR_WINDOW);     wc.hCursor = LoadCursor(0, IDC_ARROW);     wc.lpfnWndProc = WndProc;     wc.lpszClassName = _T("SuperPuperWindowClass");     RegisterClassEx(&wc);     HWND hwnd = CreateWindowEx(0, wc.lpszClassName, _T("Грузим проц на 100%"),         WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL );     ShowWindow(hwnd, nCmdShow);     UpdateWindow(hwnd);     MSG msg = {0};     while (msg.message != WM_QUIT)     {         if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))         {             TranslateMessage(&msg);             DispatchMessage(&msg);         }         else         {             render();         }     }     return 0; }

Проблема в том, что цикл крутится вхолостую даже тогда, когда нет оконных сообшений в очереди.

Нагрузку можно снизить так (по мотивам примеров из DirectX SDK):

Код

#include <tchar.h> #include <windows.h> bool isActive = false; void render(void) { } LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) {     switch (msg)     {     case WM_ACTIVATE:         isActive = wparam != WA_INACTIVE;         break;     case WM_DESTROY:         PostQuitMessage(0);         break;     default:         return DefWindowProc(hwnd, msg, wparam, lparam);     }     return 0L; } int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE, LPTSTR, int nCmdShow) {     WNDCLASSEX wc = {0};     wc.cbSize = sizeof(wc);     wc.hbrBackground = GetSysColorBrush(COLOR_WINDOW);     wc.hCursor = LoadCursor(0, IDC_ARROW);     wc.lpfnWndProc = WndProc;     wc.lpszClassName = _T("SuperPuperWindowClass");     RegisterClassEx(&wc);     HWND hwnd = CreateWindowEx(0, wc.lpszClassName, _T("Грузим проц на 100%"),         WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL );     ShowWindow(hwnd, nCmdShow);     UpdateWindow(hwnd);     MSG msg = {0};     while (msg.message != WM_QUIT)     {         BOOL haveMessage = FALSE;         if (isActive)             haveMessage = PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE);         else             haveMessage = GetMessage(&msg, NULL, 0U, 0U);         if (haveMessage > FALSE)         {             TranslateMessage(&msg);             DispatchMessage(&msg);         }         else if (isActive)         {             render();         }     }     return 0; }

Идея в том, что когда наше приложение не активно, то очередное оконное сообщение выбирается из очереди функцией GetMessage, а не функцией PeekMessage. GetMessage() не возвращает управление, пока не будет получено оконное сообщение, благодаря чему в неактивном приложении цикл останавливается.

У меня на машине первый вариант грузит проц на 100% не зависимо от того, активно ли приложение, или нет. Если работает второй вариант, то стоит переключиться на другое окно, как нагрузка падает до 0%.

Это сообщение отредактировал(а) srd - 24.10.2005, 14:05

Ну вроде кое-что проясняется. Но всё же мне не нравится тот
факт, что когда окно активно оно все равно жрёт 100%.
Видюха у меня далеко не топовая (GeForce 256 32Mb +
дрова от Nvidia), но насколько я знаю у неё есть 3д ускоритель.
Насколько я знаю в дровах должна быть аппаратная
поддержка OpenGL. Может быть по умолчанию включается
софтварный режим. И как вообще это можно узнать?

Заранее благодарен.

а почму бы и не съедать 100%, когда человек смотри 3d эффекты
ведь производительность не просто пропадает, она используется для повышения качества...
т.е. если пользователь, например, загрузит игрушку, а она ему грузит процессор на 50%, он спросит "почему не используются остальной ресурс процессора, чтобы сделать все еще красивее?"
Добавлено @ 15:59
конечно, совсем другое дело, если параллельно должны работать другие потоки или процессы... тогда уже надо как-то специфически регулировать распределение времени процессора...

Цитата(Tror @ 24.10.2005, 13:31)

Но всё же мне не нравится тот факт, что когда окно активно оно все равно жрёт 100%

Цитата(maxim1000 @ 24.10.2005, 14:58)

если параллельно должны работать другие потоки или процессы... тогда уже надо как-то специфически регулировать распределение времени процессора...

в обоих фразах нет полного понимания принципа распределения процесорного времени между приложениями.

Tror
100% загрузки - это не загрузка проца обним приложением, а показатель того, что все процесорное время занято приложениями (всеми в сумме, а не только этим), к томуже идет реч именно о времени, а не о выч. способности
например, несмотря на полную загрузку проца, остальные приложения в это время выполняються у тебя без особых тормозов (просто в это время все НЕИСПОЛЬЗОВАННОЕ время проца отдаеться этому приложению).


Добавлено @ 16:56

Цитата(Tror @ 24.10.2005, 13:31)

Насколько я знаю в дровах должна быть аппаратная поддержка OpenGL. Может быть по умолчанию включается софтварный режим.

Режим рендера только аппаратный (софтовая эмуляция присутсвует только в DirectX, в OpenGL ее и в помине нет)

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

Цитата

например, несмотря на полную загрузку проца, остальные приложения в это время выполняються у тебя без особых тормозов

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

Цитата(maxim1000 @ 24.10.2005, 16:02)

если есть приложение, которому нужно много процессорного времени (например, компиляция чего-то большого),

опять таки, не стоит путать понятия процессорное время,и нагрузка процессора, это разные вещи

Цитата

опять таки, не стоит путать понятия процессорное время,и нагрузка процессора, это разные вещи

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

Да, признаюсь что тоже выразился не совсем корректно по
поводу процессорного времени, но ситуация для меня потихоньку
проясняется. Спасибо всем кто не прошёл мимо и постарался помочь.
Но тут по ходу чтения у меня возник ещё один вопросец:
Как я понимаю основная ф-ция render() выполняется в отсутствие
каких бы то ни было сообщений, т.е. всё свободное время уходит на
отрисовку сцены и чем больше раз выполняется render(), тем больше
fps. Собственно вопрос: если имеется
довольно мощная видюха и проц, то fps бывает зашкаливает за
нормальные 50-60(сам видел у друга на X850 fps = 500), т.е. мощность
тратится впустую. Можно ли ограничивать fps каким то определённым
значением, а всё оставшееся время использовать для расчётов. И,
вообще, целесообразно ли исползовать многопоточность в графических
приложениях. Если что не так поправьте.

Заранее благодарен.

Цитата

Можно ли ограничивать fps каким то определённым значением, а всё оставшееся время использовать для расчётов.

очень просто:
1. делаешь WaitableTimer на 1/50 секунды (для 50 fps)
2. вызываешь render()
3. вызываешь WaitForSingleObject

если render() отработала быстрее, оставшееся время поток будет заморожен и процессор ним использоваться не будет

если за 1/50 не успела, WaitForSingleObject сразу возвратится, и сразу начнется обработка следующего кадра

P.S.
про все, что связано с WaitableTimer и WaitForSingleObject можно почитать в MSDN...

maxim1000
А есть гарантия, что в результате "замораживания" основного потока с помощью WaitForSingleObject() активизируются другие потоки именно нашего приложения, а не какого-нибудь постороннего?

Цитата

А есть гарантия, что в результате "замораживания" основного потока с помощью WaitForSingleObject() активизируются другие потоки именно нашего приложения, а не какого-нибудь постороннего?

я не знаю тонкостей алгоритмов распределения процессорного времени между потоками и процессами Windows, но думаю, такой гарантии не будет

с другой стороны, если в это время не будет запущено каких-то "все время что-то делающих" приложений, наверное, бОльшая часть отойдет нашим (если они не будут замороженны, конечно)
Добавлено @ 14:17
можно, конечно, чего-нибудь поколдовать с приоритетами, но я с ними не работал...

Цитата(srd @ 25.10.2005, 13:49)

А есть гарантия, что в результате "замораживания" основного потока с помощью WaitForSingleObject() активизируются другие потоки именно нашего приложения, а не какого-нибудь постороннего?

Вы вообще как себе многозадачность представляете? Это все равно что сравнивать линейное программирование и ООП. На ваш процес выделяется некоторое количество квантов процессорного времени. Другие процессы выполняются теоретически "параллельно". Если ваша задача не будет требовательна к ресурсам, а их в системе будет нехватка, то процеесороное время будет отданно процессу с большим приоритетом. Внутри процееса квант распеределяется между потоками. Не считая того, что процов может быть два или пень с HP. Тогды часть процессов в некоторыемоменты времени может выполняться одновременно для двух разных задач.

Цитата(Tror @ 25.10.2005, 13:28)

Как я понимаю основная ф-ция render() выполняется в отсутствие каких бы то ни было сообщений, т.е. всё свободное время уходит на отрисовку сцены

Честно говоря в лом разбираться в коде, но нужно иметь в виду, что в хорошем OGL приложении сцена перерисовывается в двух случаях:
1)По требованию ОС перерисовать часть окна или все окно целиком.
2)Если изображение изменилось

Цитата(DENNN @ 25.10.2005, 23:05)

Внутри процееса квант распеределяется между потоками.

Тут я запутался. "Квант" выделяется именно процессу, а не потоку? Т.е. под "квантом" подразумевают обычно нечто неделимое, как он может распределяться между потоками?

У Рихтера:

Цитата

Процессы инертны Чтобы процесс что-нибудь выполнил, в нем нужно создать поток Именно потоки отвечаю за исполнение кодя, содержащегося в адресном про странстве процесса В принципе, один процесс может владеть несколькими потока ми, и тогда они "одновременно" исполняют код в адресном пространстве процесса. Для этого каждый поток должен располагать собственным набором регистров про цессора и собственным стеком В каждом процессе есть минимум один поток. Если бы у процесса не было ни одного потока, ему нечего было бы делать на этом свете, и система автоматически уничтожила бы его вместе с выделенным ему адресным про странством. Чтобы всс эти потоки работали, операционная система отводит каждому из них определенное процессорное время. Выделяя потокам отрезки времени (называемые квантами) по принципу карусели, она создает тем самым иллюзию одновременного выполненияпотоков

Под квантом понимается временной отрезок, в течении которого управление будет переданно процессу и не будет выполняться проверка о необходимости передачи управления другому процессу. Как расперделяется время медлу потоками внутри процесса - вопрос немножко другой. Неделимым может быть отрезок и в 2 кванта и более. Обычно квант - верменной промежуток, меньше которого квантовать время не отимально. Это все грубо и достаточно неточно, но как суме, так и сказал. ...

Почитал тут посты, возникло предложение (не пинайте ногами сильно): что мешает перерисовывать кадр только когда это надо ? Например, мышка не двигалась, объекты в сцене не изменили своё положение, эффекты "молчат" -- нафига рисовать "поверх" того же самого ?

З.Ы, можно простым способом сделать: глобальная статическая переменная типа HANDLE с каким-нибудь объектом синхронизации, и ждущий поток. Поток рендерит кадр, потом "засыпает" в WaitForSingleObject. Если другие потоки, к примеру, передвинули камеру или объект в сцене - они сигналят первому потоку, он просыпается и рендерит ещё один кадр .

Цитата(Tror @ 25.10.2005, 13:28)

Можно ли ограничивать fps каким то определённым значением, а всё оставшееся время использовать для расчётов. И, вообще, целесообразно ли исползовать многопоточность в графических приложениях. Если что не так поправьте.

Именно это и получится, если сделать как я предложил. Сигналить-то можно с любой требуемой скоростью.

Даа , я тут посмотрю придётся мне немног попотеть, чтоб разобраться во всём том, что
здесь написали. Большое всем спасибо -- дали пищу для размышлений. Всё, пошёл разбираться.

о распределении времени:
я просто представил себе два возможных способа распределения времени:
1. глобально между процессами (независимо от количества активных потоков) и внутри них уже свои локальные шедулеры, которые делят полученное время между потоками
2. просто между процессами

в первом случае от замораживания потока доля процесса в использовании процессора не меняется, значит, при замораживании одного из потоков, его время будет распределено между остальными потоками этого же процесса

во втором случае усыпление одного из потоков приведет к распределению его части процессорного времени между всеми потоками в системе, а значит к потокам нашего процесса попадет только часть

Цитата

Почитал тут посты, возникло предложение (не пинайте ногами сильно): что мешает перерисовывать кадр только когда это надо ? Например, мышка не двигалась, объекты в сцене не изменили своё положение, эффекты "молчат" -- нафига рисовать "поверх" того же самого ?

насколько я понимаю, речь идет именно о моментах, когда что-то меняется, например, летят ут... пули, чем чаще будем менять картинку, тем плавнее они будут лететь...
и если моментов, когда вообще ничего не меняется становится ощутимая часть, тогда стоит подумать о какой-то специальной обработке (т.е. отключении отрисовки) этой ситуации...
другой вопрос - а часто ли такие моменты встречаются?

Цитата(mr @ 25.10.2005, 19:05)

Почитал тут посты, возникло предложение (не пинайте ногами сильно): что мешает перерисовывать кадр только когда это надо ?

Читаем внимательно пердыдущую страницу:

Цитата(DENNN @ 25.10.2005, 15:05)

сцена перерисовывается в двух случаях: 1)По требованию ОС перерисовать часть окна или все окно целиком. 2)Если изображение изменилось

В общем разобрался я в чем тут дело. Оказывается весь сыр-бор из-за того как мы выбираем
сообщения из очереди. Если использовать PeekMessage, то в таскмане отображается
использование проца на 100%, если же использовать GetMessage, то всё в порядке. Но тут возникает проблемка: при использовании PeekMessage всё в норме, а при GetMessage рабочая область программы закрашивается тем что было до нее на экране(окна, десктоп и тд). Посмотрел
в win32sdk help, там в ремарках к PeekMessage написано только то что он не ждёт окончания обработки сообщения в отличие от GetMessage. Глубже мне не удалось разобраться ввиду отсутствия MSDN(но вроде обещали подогнать), а пользоваься им в онлайне нет возможности.


То maxim1000:
С днём рождения

Это сообщение отредактировал(а) Tror - 26.10.2005, 21:01