Отладка OpenGL ES 2.0

Итак, у меня есть приложение OpenGL ES 2.0. Он компилируется и запускается в симуляторах iPhone/iPad, на реальном iPhone/iPad и под Windows с использованием библиотек эмулятора Imgtec (например, PVRVframe).

В указанном приложении у меня есть один конкретный вызов отрисовки, который приводит к тому, что пиксели не записываются в цель, хотя все состояние, которое я могу запросить, выглядит разумным (окно просмотра, тест глубины / тест трафарета / отбраковка / смешивание выключено, кадровый буфер завершен и т. д.), и AFAICT Я отправляю разумные данные вершины.

На данный момент мне нужен инструмент Pix / GPAD, который позволит мне пройтись по сцене и просмотреть состояние, которое я не могу напрямую запрашивать из OpenGL в данный момент. рассматриваемого вызова отрисовки (например, фактическое содержимое буфера вершин/индексов).

Ни PVRTrace, ни инструменты OSX не фиксируют достаточное количество состояний для отладки такого рода проблем. В частности, они не захватывают буфер вершин/индексов или данные текстуры (инструменты OSX также не захватывают источник шейдера).

gDEBugger, ранее отвечавший на подобные вопросы в Stack Overflow, теперь находится в версии 5.8 — он стал бесплатным, что приятно, но больше не поддерживает OpenGL ES 2 (под Windows нет возможности рендеринга ES2). config доступен через EGL; в OSX нет возможности подключить отладчик к приложению, работающему ни в симуляторе, ни на реальном устройстве) — что не так приятно.

Я упускаю что-то очевидное? Каковы мои варианты? Как другие отлаживают свои сцены?


debugging opengl-es-2.0
person moonshadow    schedule 25.03.2011    source источник
comment
Для справки, теперь я решил проблему, с которой я столкнулся; это действительно было до состояния, не захваченного ни одним из вышеупомянутых инструментов и не запрашиваемого через OpenGL. На поиски ушло утро; проблема была бы очевидна с первого взгляда, если бы у меня был полный дамп состояния. Так что я все еще хочу получить ответ, в следующий раз :)   -  person moonshadow    schedule 25.03.2011
comment
...прошла неделя, и теперь пришло время в следующий раз. Конечно, разумные инструменты должны существовать где-то, верно? Правильно?   -  person moonshadow    schedule 01.04.2011

Ответы (3)


arrow_upward
4
arrow_downward

Это возможно в Xcode, начиная с версии 4.2, ср. https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_4_2.html#//apple_ref/doc/uid/00200-SW5

person Alexis Pribula    schedule 09.03.2012
comment
Средство захвата кадра Xcode теперь достаточно развито для отладки почти всех проблем. Мы обнаружили, что не можем использовать его на устройствах эпохи iPad1 для сложных кадров, поскольку на устройстве заканчивается память, но это, конечно, не непреодолимая проблема. Обратите внимание, что вы должны убедиться, что рабочая область Xcode включает в себя инфраструктуру OpenGL ES, даже если у вас есть какой-то внешний процесс, фактически создающий ваши сборки (мы используем Jam), в противном случае средство захвата кадра будет отключено без объяснения причин — надеюсь, это спасет кого-то еще когда-то :) - person moonshadow; 07.09.2012

arrow_upward
8
arrow_downward

Существует несколько инструментов отладки OpenGL ES 1.1/2.0 от поставщиков графических процессоров. Почти для этих инструментов требуется реальное устройство, но Imagination Technologies предоставляет библиотеки эмуляции и инструмент трассировки, которые вы использовали. Вы использовали PVRTrace с PVRVFrame?

(Я считаю, что gDEBugger 5.7 — лучший инструмент для отладки OpenGL ES 1.1/2.0. Но его больше нет...)

person Kazuki Sakamoto    schedule 05.04.2011
comment
Я посмотрел на PVRTrace, как я объясняю в своем вопросе. Он не захватывает текстуру или содержимое буфера вершин/индексов (или, возможно, не может их отобразить) и (что менее важно) не обеспечивает способ пошагового перемещения по кадру и отображения результатов конкретного вызова отрисовки, как зрелые отладчики, такие как Pix. и GPAD делать. Более того, я заметил, что состояние, отображаемое в средстве просмотра состояния, не совпадает с состоянием, сообщаемым коду с помощью glGet() для конкретных вызовов, а результаты на экране подразумевают, что это была ошибка PVRTrace. Это делает его ограниченным в использовании. У меня нет доступа к устройствам Adreno или Mali. - person moonshadow; 05.04.2011
comment
Профилировщик Adreno отлично подходит для профилирования, но, как и в случае с PVRTrace, он не фиксирует достаточное количество состояний для отладки. - person moonshadow; 15.09.2011

arrow_upward
3
arrow_downward

Я обнаружил, что gDebugger 5.7 для Windows все еще доступен здесь:

http://files.gremedy.com/downloads/gDEBugger-5_7.msi

Я изменил этот URL-адрес по сравнению с тем, который находится в верхней части этой страницы загрузки: источник просмотра:http://www.gremedy.com/downloading.php?platform=windows32

Можно получить доступ к той же версии для других платформ с помощью того же трюка.

Старый файл лицензии доступен здесь: http://www.geeks3d.com/20101207/3d-programming-gdebugger-advanced-opengl-debugger-now-free/

Но он истек 31 января 2011 года.

person XenonofArcticus    schedule 02.01.2012
comment
Последний выпуск gDEBugger, 5.8.1, больше не требует лицензии: gremedy.com/download.php - person Nathan Monteleone; 14.12.2012
comment
Рабочая ссылка gDebugger 5.8.1 для Windows: yun.baidu.com/s/1jGMeSCm - person Joseph; 06.04.2017