EGL / OpenGL ES / контекст переключения медленный

Я разрабатываю приложение OpenGL ES 2.0 (с использованием Angleproject в Windows для разработки), которое состоит из нескольких «фреймов».

Каждый фрейм представляет собой изолированное приложение, которое не должно мешать окружающим фреймам. Фреймы отрисовываются с использованием OpenGL ES 2.0 кодом, работающим внутри этого фрейма.

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

Моя следующая попытка заключалась в использовании контекста для каждого кадра. Я создал уникальный контекст для каждого кадра. Я использую общие ресурсы, так что я могу eglMakeCurrent для каждого кадра, рендерить каждый в свой собственный буфер / текстуру кадра, а затем eglMakeCurrent обратно на глобальный уровень, чтобы скомпоновать каждую текстуру для финального экрана.

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

Какой подход я могу выбрать? Есть ли способ ускорить переключение контекста или избежать переключения контекста, каким-то образом сохраняя состояние OpenGL для каждого кадра?


opengl-es egl
person Andrew Price    schedule 07.08.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

У меня есть предложение, которое может устранить накладные расходы eglMakeCurrent, позволяя вам использовать ваш текущий подход.

Концепция текущего EGLContext является локальной для потока. Я предлагаю создать все контексты в главном потоке вашего процесса, а затем создать по одному потоку для каждого контекста, передавая по одному контексту каждому потоку. Во время инициализации каждого потока он вызывает eglMakeCurrent в контексте, которым он владеет, и никогда больше не вызывает eglMakeCurrent. Будем надеяться, что в реализации ANGLE локальное для потока хранилище контекстов реализовано эффективно и не имеет ненужных накладных расходов на синхронизацию.

person Chadversary    schedule 14.08.2013

arrow_upward
-1
arrow_downward

Проблема здесь в попытке сделать это универсальным способом, независимым от платформы и ОС. Если вы выбираете конкретную платформу, есть хорошие решения. В Windows есть библиотеки wgl и glut, которые предоставят вам несколько окон с полностью независимыми контекстами OpenGL, работающими одновременно. Они называются Windows, а не Frames. Вы также можете использовать DirectX вместо OpenGL. Угол использует DirectX. В Linux решением является X11 для OpenGL. В любом случае очень важно иметь качественные драйверы OpenGL. Нет драйверов для набора микросхем Intel Extreme. Если вы хотите сделать это на Android или iOS, тогда потребуются другие решения. На форуме Khronos.org OpenGL ES недавно появилась ветка о корпусе Android.

person ClayMontgomery    schedule 07.08.2013
comment
Проблема с eglMakeCurrent существует на многих платформах даже при использовании предоставленных платформой библиотек EGL и OpenGL ES напрямую, минуя ANGLE. Основная проблема заключается в том, что eglMakeCurrent часто является дорогостоящим вызовом, потому что спецификация EGL фактически требует, чтобы драйвер внутренне вызвал glFlush перед возвратом eglMakeCurrent. glFlush может сжигать много ресурсов процессора. Обмен EGLContext также требует проверки драйвером его внутреннего конечного автомата GL. - person Chadversary; 11.11.2016