#c #performance #opengl #yocto #mesa
#c #Производительность #opengl #yocto #mesa
Вопрос:
Я использую Yocto в качестве встроенной системы с OpenGL 2.1, GLEW 2.0.0 и Mesa 17.0.2. Я выполняю программную визуализацию за кадром на мониторе через HD / SDI. Проблема, с которой я сталкиваюсь, заключается в том, что моя частота обновления составляет около 1 Герц. На моей машине разработки у меня около 20 кадров в секунду, когда аппаратное ускорение отключено в Debian. Встроенная машина не такая мощная, поэтому я понимаю, что производительность упала, но 1 кадр / с кажется немного низким. Для своей оптимизации я отключил:
glDiasble(GL_LINE_SMOOTH)
glDiasble(GL_POINT_SMOOTH)
glDiasble(GL_SMOOTH)
glDiasble(GL_MULTISAMPLE)
glShadeModel(GL_NONE)
У меня нет никакого отбора, потому что я использую только 2D-изображения.
Однако я устанавливаю фильтр min и mag на GL_NEAREST.
Моя замена буфера и создание контекста — это что-то вроде:
bool makeContext()
{
width = 1280;
height = 720;
context = OSMesaCreateContextExt(OSMESA_RGBA, 0, 0, 0, NULL);
if(!context)
{
//...
return false;
}
bufferSize = width * height * 4 * sizeof(GL_UNSIGNED_BYTE);
frameBuffer = (char*)mallic(bufferSize);
frameBuffer = (char*)0_buf_baseaddr;
if(!OSMesaMakeCurrent(context, frameBuffer, GL_UNSIGNED_BYTE, width, height));
{
//...
return false;
}
OSMesaPixelStore(OSMESA_Y_UP, 0)
{
//...
}
return true;
}
void swapBuffers()
{
frameBuffer = (char*) swap_page(); //returns a spot in memory with update
OSMesaMakeCurrent(context, frameBuffer, GL_UNSIGNED_BYTE, width, height);
}
Я думал о применении трафаретной печати, но я не уверен, что это улучшит производительность. Я почти уверен, что проблема связана с интенсивным использованием альфа-каналов в моих изображениях, которые я использую. Несколько движущихся слоев друг за другом для получения желаемых эффектов.
Есть ли что-то не так с моей заменой или созданием, что очевидно? Кроме того, на основе уже выполненных мной оптимизаций, могу ли я сделать что-нибудь еще, что могло бы помочь?
Комментарии:
1. Каковы характеристики вашей встроенной цели (скорость процессора, пропускная способность памяти и т.д.)? Уменьшите размер фреймбуфера примерно до 320×240. 1280×720 — это много пикселей для встроенной цели, а тем более для настольного оборудования. Имеет ли ваш встроенный целевой объект несколько ядер? Если да, используете ли вы серверную часть llvmpipe? По умолчанию он многопоточный.
2. Проверьте, поддерживает ли ваш Mesa
glInvalidateFramebuffer()
сквознойARB_invalidate_subdata
, это может быть быстрее, чем прямыеglClear()
s.3. Отличные вопросы, скорость процессора на данный момент неизвестна, а максимальная память составляет два гигабайта. Что касается уменьшения размера буфера, не изменит ли это расположение моих изображений на экране? Допустим, у меня есть изображение, расположенное на 722, 240 (случайная точка). Будет ли это теперь отображаться вне контекста? И поскольку у меня есть тест «ножницы», вырезать все вместе? Кроме того, я проведу исследование glInvalidateFramebuffer, как вы упомянули. Все это замечательные моменты, большое вам спасибо.
4. Четырехъядерный процессор ARM с частотой 1,5 ГГц
5. У вашего ARM есть драйверы GL, верно? Если драйверы отсутствуют, Mesa вернется к программной визуализации. Обратите внимание, что ARM обычно не имеет GL, и большинство драйверов являются GLE.
Ответ №1:
Я смог увеличить производительность на ~ 10%, удалив и обработав некоторые изображения ресурсов. В основном, это делает мой glClear цветом самого дальнего изображения (на один ресурс меньше для рисования), а затем накладывает поверх моих изображений альфа-каналы. Мой графический интерфейс в значительной степени зависит от альфа-каналов, поэтому даже на один вызов draw меньше влияет на программный рендеринг.
Комментарии:
1. Кроме того, из gitlab.freedesktop.org/mesa/demos/tree/master/src/demos . Похоже, что ожидается ~ 1 кадр / с без какой-либо аппаратной поддержки при использовании интенсивного наложения. Помещаю это здесь на случай, если кто-то другой столкнется с чем-то подобным.