Частота кадров приложения OpenGL ухудшилась после обновления с iOS7.1 до iOS8.1

Приложение использует OpenGL ES2 и инфраструктуру GLKit, а также цикл рендеринга/обновления, предоставляемый GLKitViewController. Раньше он работал со стабильной скоростью 60 кадров в секунду на моем iPad2 с iOS7.1, но как только я обновил iPad2 до iOS8.1, точно такой же код теперь колеблется между 56-59 кадрами в секунду. (Загрузка процессора, однако, остается на уровне 40-60%, как и раньше).

Профилирование показывает, что команды рисования OpenGL используют гораздо большую долю процессорного времени, чем раньше. Самое большое изменение, по-видимому, заключается в том, что вызовы «GLKBaseEffect prepareToDraw» занимают гораздо больше времени, чем раньше.

(Приложение использует один GLKBaseEffect, который перенастраивается в различных точках цикла рендеринга, что требует каждый раз вызова prepareToDraw. Я понимаю, что можно оптимизировать, имея несколько экземпляров GLKBaseEffect, и это то, что я рассматривал позже. , однако производительность и так была стабильной на iOS7.1)

Сейчас я изучаю трассировку OpenGL ES Analyzer в Instruments, чтобы определить вызовы OpenGL, сгенерированные «GLKBaseEffect prepareToDraw», чтобы увидеть, не кажется ли что-то необычным, и соответствующим образом обновлю сообщение, как только мне удастся что-то выяснить.

Я был бы очень признателен за любые указания о том, как двигаться дальше — почему вызовы GLKBaseEffect prepareToDraw могут занимать больше времени в iOS8.1?


ios glkit opengl-es-2.0 glkbaseeffect ios8.1
person Amral    schedule 08.12.2014    source источник
comment
Если вы обнаружили значительную регрессию, вам следует зарегистрировать ее в Apple (bugreport.apple.com) сразу после случае это ошибка. Если вы можете предоставить пример кода, это поможет им. В качестве альтернативы вы можете использовать инцидент технической поддержки (TSI) и посмотреть, может ли инженер Apple помочь вам напрямую. Кроме того, сообщение SO о медленном OpenGL: stackoverflow.com/q/22562091/558933   -  person Robotic Cat    schedule 08.12.2014
comment
@RoboticCat Спасибо, я попытаюсь провести сравнительное тестирование на устройстве iOS7.1, если смогу, а затем отправлю отчет. Трассировка OpenGL Analyzer не показала ничего необычного — команды GL, сгенерированные prepareToDraw, казались разумными, но я проверю их завтра утром, так как здесь уже поздно. Я тоже не знал о TSI, спасибо.   -  person Amral    schedule 08.12.2014
comment
Я могу подтвердить, что GLKBaseEffect prepareToDraw генерирует много ненужных вызовов glGetIntegerv(GL_CURRENT_PROGRAM,...) и glGetUniformLocation(). Унифицированные местоположения не меняются, если, например, программа не перекомпоновывается, и я ожидал, что GLKBaseEffect будет кэшировать эти местоположения в памяти, доступной для ЦП. Однако я не знаю, генерировались ли те же вызовы в iOS7, так что это может быть не проблема.   -  person Amral    schedule 09.12.2014
comment
Я нашел эту тему на форумах Apple: Падение производительности OpenGL › 50% в iOS 8 GM ссылка В iOS8 установка текстового поля в UIView, встроенном в основной GLKView, неправильно приводила к макету суперпредставления, что затем неправильно приводило к освобождению/перераспределению кадровых буферов. У меня есть UIView, встроенный в GLKView, хотя большую часть времени он невидим и обновляется только раз в секунду, а не раз в кадр. Я смогу проверить позже сегодня, является ли это причиной проблемы, и сообщу.   -  person Amral    schedule 09.12.2014

Ответы (1)


arrow_upward
0
arrow_downward

Причина проблемы была определена Джимом Хиллхаусом и подтверждена Frogblast в ветке форума Apple Dev Forums "Производительность OpenGL падает на 50% в iOS 8 GM": установка свойства text UITextField (или UILabel, в моем случае) в представлении, которое является подпредставлением GLKView, приводит к макетированию суперпредставления GLKView, что затем приводит к освобождению и перераспределению кадровых буферов. В iOS 7 этого не было.

Обходной путь Джима Хиллхауса заключался в том, чтобы поместить подвид внутри UIViewController и встроить его в GLKView. Я сделал то же самое, используя Container View для хранения контроллера представления, и могу подтвердить, что он работает.

person Amral    schedule 10.12.2014