Странное использование процессора в программе OpenGL - PullRequest
0 голосов
/ 28 апреля 2011

В MFC-программе, которую я создал сам, у меня есть некоторые странные проблемы с использованием процессора.

Я загружаю облако точек около 360 тыс. Точек, и все работает нормально (я использую буферы VBO, как это сделать из того, что я понимаю?). Я могу перемещать его по своему усмотрению и не замечать побочных эффектов (загрузка процессора очень низкая, GPU выполняет всю работу). Но затем при определенных углах и значениях масштабирования я вижу всплеск процессора на одном из моих процессоров! Затем я могу изменить угол или немного увеличить изображение, и оно снова опустится до 0. Это чаще происходит в большом окне, чем в маленьком.

Я измеряю FPS программы, и он постоянно равен 65, но когда происходит всплеск ЦП, он обычно падает примерно с 10 до 55. Я также измеряю время, которое занимает SwapBuffers, и при нормальной работе оно составляет около 0-1 мс. После того, как всплеск ЦП достигнет примерно 20 мс, становится ясно, что в этой функции что-то внезапно становится очень сложно вычислить (для GPU, я полагаю?). Этого чего-то нет в функции DrawScene (это та функция, которую можно ожидать, если съесть процессор в плохой реализации), поэтому я немного растерялся.

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

Я очень новичок в OpenGL, поэтому не исключено, что я совершил совершенно очевидную ошибку.

Вот так выглядит цикл рендеринга (он запускается в приложении MFC через событие таймера с периодом 1 мс):

    // Clear color and depth buffer bits
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    // Draw OpenGL scene
    OGLDrawScene();

    unsigned int time1 = timeGetTime();

    // Swap buffers
    SwapBuffers(hdc);

    // Calculate execution time for SwapBuffers
    m_time = timeGetTime() - time1;

    // Calculate FPS
    ++m_cnt;
    if (timeGetTime() - m_lastTime > 1000)
    {
        m_fps = m_cnt;
        m_cnt = 0;
        m_lastTime = timeGetTime();
    }

Ответы [ 2 ]

1 голос
/ 31 июля 2011

Я заметил, что (по крайней мере, некоторое время назад) драйверы ATI, как правило, слишком агрессивно предпочитают вращаться с задержкой, в то время как драйверы NVidia, как правило, управляются прерываниями. Технически ожидание вращения быстрее, если вам нечего делать лучше. К сожалению, сегодня у вас, вероятно, есть что-то лучше сделать в другом потоке.

Я думаю, что драйверы дисплея OP действительно могут быть ожидающими вращения.

0 голосов
/ 29 апреля 2011

Хорошо, я думаю, что понял, как это может произойти.

Для начала сообщения WM_TIMER, по-видимому, генерируются не чаще, чем каждые 15 мс в лучшем случае, даже при использовании timeBeginPeriod (1), по крайней мере, на моем компьютере. Это привело к стандартным 65 кадрам в секунду, которые я видел.

Как только для рендеринга сцены потребовалось более 15 мс, SwapBuffers станет вместо этого ограничивающим фактором. SwapBuffers, кажется, заняты ожиданием, что привело к 100% загрузке ЦП на одном ядре, когда это произошло. Это не то, что происходило под определенными углами камеры, но это результат плавного изменения fps в зависимости от того, сколько точек было показано на экране в то время. Похоже, что оно всплывало всякий раз, когда рендеринг достигал времени более 15 мс, и вместо этого начинал ждать в SwapBuffers.

На аналогичной ноте кто-нибудь знает о функции, такой как "glReadyToSwap" или что-то подобное? Функция, которая указывает, готовы ли буферы к обмену? Таким образом, я мог бы выбрать другой метод для рендеринга с более высоким разрешением (например, 1 мс), а затем каждую мс проверять, готовы ли буферы поменяться местами, если они не просто ждут еще одну мс, чтобы не занято-ожидание.

...