После смены Debian 6 на 7 быстродействие программы упало на ПОРЯДОК

[MiK13]

Здравствуйте!
Проблема такая. Разрабатываем программу для управления некоторым процессом и отображением информации о его ходе.
Программа работала под Squeeze вроде нормально.Но для более качественного управления процессом начальник потребовал использовать реальное время. Нашли патч, чтобы добавить в ядро Real Time, собрали ядро, но на мониторе не смогли установить нормальное разрешение, 1600x1200. Попробовали Debian 7 Wheezy, там есть ядро с буквами "rt". С ним как-то через ... файл xorg.conf удалось установить в иксах разрешение монитора 1600x1200. Но обнаружилось, что программа стала ужасно сильно тормозить.Причём оказалось, что основной "тормоз" приходится на вывод растрового изображения через функцию glDrawPixels. Стал проверять с более простой программой. Если под Debian 6 она выводит изображение со скоростью примерно 20 кадров в секунду (и при этом top показывает, что она занимает примерно 50% процессорного времени), то под Debian 7 скорость вывода составляет 1-2 кадра в секунду. И top показывает, что больше 70% процессора занимает Xorg.
Процессор

Код: Выделить всё

vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     L7500  @ 1.60GHz
stepping        : 11

Проверил на ноутбуке ASUS X200MA с процессором Intel Celeron Dual-Core 2 x 2.16 ГГц аналогичная картина (чуть лучше): 2-3 кадра в секунду (top не смотрел)

Проверяли утилитой glxgears. Под Debian 6 показывает в районе 800 FPS, под Debian 7 -- примерно 60 FPS.
На ноутбуке также 60 FPS (там стоит Jessie). На моём рабочем компьютере (с Wheezy) 1300 FPS.

В каком направлении решать эту проблему? Как обеспечить "нормальный" вывод растровой картинки на экран с масштабированием?

[SLEDopit]

А видеокарта какая? И драйвера какие на debian 6 и 7 стоят?

[Bizdelnick]

Нашли патч, чтобы добавить в ядро Real Time, собрали ядро, но на мониторе не смогли установить нормальное разрешение, 1600x1200. Попробовали Debian 7 Wheezy, там есть ядро с буквами "rt".

А выдать программе соответствующий приоритет не забыли, или решили, что букв "rt" будет достаточно?
Вообще графическую программу с приоритетом реального времени запускать — IMHO не лучшая идея, лучше использовать клиент-серверную архитектуру, и в rt запускать только бекенд. Да, фронтенд в таком случае будет тормозить, если только не перенести его на отдельную машину с обычным ядром. За RT надо платить.

Проверяли утилитой glxgears. Под Debian 6 показывает в районе 800 FPS, под Debian 7 -- примерно 60 FPS.

Читать то, что пишет в консоль glxgears, не пробовали? Ну или погуглить google://glxgears 60 fps. Месяца не проходит, чтобы кто-нибудь на это не пожаловался...

[Stauffenberg]

Программирование-то тут причем?

[MiK13]

А выдать программе соответствующий приоритет не забыли, или решили, что букв "rt" будет достаточно?
Вообще графическую программу с приоритетом реального времени запускать — IMHO не лучшая идея, лучше использовать клиент-серверную архитектуру, и в rt запускать только бекенд.

В смысле отдельным процессом?
Я, когда познакомился с возможностями Linux и его иксов, решил, что наиболее "удобным" вариантом будет разработка отдельных программ для решения определённых задач. Но большинство решило, что всё должно быть собрано в одной программе. И программа должна быть написана на QT (требование начальника). И в рамках этой программы должны запускаться отдельные процессы, которые будут решать определённые задачи. И с задачей, требующей RT я даже не знаком (знаю только, что управление каким-то приводом).

Но основная проблема не в этом.

Проверяли утилитой glxgears. Под Debian 6 показывает в районе 800 FPS, под Debian 7 -- примерно 60 FPS.

Читать то, что пишет в консоль glxgears, не пробовали? Ну или погуглить google://glxgears 60 fps. Месяца не проходит, чтобы кто-нибудь на это не пожаловался...

Читали.

Код: Выделить всё

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
6418 frames in 5.0 seconds = 1283.469 FPS
6564 frames in 5.0 seconds = 1312.667 FPS
6531 frames in 5.0 seconds = 1306.184 FPS

Работа синхронизируется с вертикальной развёрткой. Развёртка 1300 кадров в секунду? Хотя это хорошо объясняет 60 FPS. Но почему под Squeeze ТА ЖЕ САМАЯ программа показывает 800 FPS? Т.е. почему ТАМ она не смотрит на развёртку?
И ещё: на ноутбуке при 60 FPS колёсики крутятся довольно плавно. А вот на промышленном компьютере CPC 506 под Wheezy они как-то очень медленно дёргаются, хотя там тоже 60 FPS.

Но всё это мелочи, и основная проблема в другом: под Squeeze программа через функцию glDrawPixels выводит до 20 кадров в секунду, а под Wheezy только 1-2. Т,е. впечатление, что не используются полностью средства OpenGL. И основные вопросы: почему? И как их использовать?

А видеокарта какая? И драйвера какие на debian 6 и 7 стоят?

Видеокарта -- встроенная на i915. Драйвера -- те, что поставились по aptitude install xorg.

[Bizdelnick]

В смысле отдельным процессом?

Да.

большинство решило, что всё должно быть собрано в одной программе. И программа должна быть написана на QT (требование начальника).

Тогда забудьте про RT. (IMHO)

с задачей, требующей RT я даже не знаком

Тогда о чём мы тут вообще говорим? Я тем более не знаком.

Но почему под Squeeze ТА ЖЕ САМАЯ программа показывает 800 FPS? Т.е. почему ТАМ она не смотрит на развёртку?

Это не та же самая программа, а её более старая версия. Но причина скорее всего не в этом, а в другом (более старом) видеодрайвере, который может просто не отдавать информацию о частоте развёртки. В любом случае ориентироваться на выводимые glxgears цифры нельзя.

под Squeeze программа через функцию glDrawPixels выводит до 20 кадров в секунду, а под Wheezy только 1-2.

Ядро в обоих случаях обычное, или во втором — RT? Если сравниваете не-RT с RT, то это нормально. И что колёсики дёргаются — тоже нормально. Задача RT-ядра — обеспечить гарантированное время отклика для критичных процессов. Другие процессы при этом могут (и будут) лагать.

[MiK13]

большинство решило, что всё должно быть собрано в одной программе. И программа должна быть написана на QT (требование начальника).

Тогда забудьте про RT. (IMHO)

Остаётся убедить в этом начальника

Это не та же самая программа, а её более старая версия.

Но исполняемый файл один и тот же, я его просто перенёс через флешку.

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

На это очень похоже.

В любом случае ориентироваться на выводимые glxgears цифры нельзя.

Это я уже понял. И меня с самого начала удивила близость скорости к число 60. Но смутило то, что "падение быстродействия" при переходе от 6 к 7 было примерно таким же, как и в программе, которая никак не завязана на развёртку.

под Squeeze программа через функцию glDrawPixels выводит до 20 кадров в секунду, а под Wheezy только 1-2.

Ядро в обоих случаях обычное, или во втором — RT? Если сравниваете не-RT с RT, то это нормально. И что колёсики дёргаются — тоже нормально. Задача RT-ядра — обеспечить гарантированное время отклика для критичных процессов. Другие процессы при этом могут (и будут) лагать.

В том-то и дело, что ядро RT ещё не ставили. Да и никакие другие задачи "RT" не запускали. Работал только GNOME, терминал, mc и основные службы.

[Bizdelnick]

Работал только GNOME

GNOME3 неслабо ресурсов отжирает, может в этом дело? Попробуйте MATE из бекпортов поставить.

[Janik]

glDrawPixels

Не используйте его, лучше загружать в текстуру и выводить как квадрат.

[MiK13]

glDrawPixels

Не используйте его, лучше загружать в текстуру и выводить как квадрат.

Попробую разобраться с текстурами. Но дело, скорее всего, не в этом.
Недавно обнаружил, что в одной программе не работает один элемент, окно, в котором я рисую гистограмму. Точнее, она рисуется, но только в начале.
Потом обнаружил, что на другом компе всё работает. Переписал эту программу на свой комп -- не работает.
Видимо, причина в том, что в Wheezy заменили glut на freeglut и ряд запросов перестал работать.

[Janik]

заменили glut на freeglut

В дебиане вроде изначально freeglut.